Old thread, but catching up with old posts, and no replies here. No, it won't. All it does is control a flag that goes into the exe header so the OS knows what size process to run it in. You can even change this post-build if you want (corflags.exe).
Adding a native compilation step is another matter, lots of perf gains to be had there, but only really for app startup (once the jitter does is stuff it's native anyway, that's the point), and then your binary is architecture specific not just bit size specific - won't run on ARM devices. Like RPi etc... All the hardcore x64 optimisations are in the runtime, not the IL compiler. (This all just what I've learnt over the years BTW so still non primary source - I could be wrong) On 23 Jun 2016 3:58 pm, "Greg Keogh" <[email protected]> wrote: > Folks (including any Microsoft boffins on this subject), > > When I read Joe Duffy's book Framework 2.0 > <https://www.amazon.com/Professional-NET-Framework-2-0-Programmer/dp/0764571354> > 10 years ago he clarified how the .NET compilers generate platform agnostic > IL which is JIT'd into native code at runtime appropriate for the > architecture. This makes perfect sense, and as a result I have set every > project I've ever created to "Any CPU" and simply trusted all the tools in > the pipeline to execute my code in the best way it chooses. > > Now that almost all desktop and server machines are running 64-bit > Windows, I want to know if there is any advantage of any kind in changing > my compile projects and installer (vdproj) projects to target x64. I > personally suspect there will be no performance change or any other > advantage, but I'll like confirmation of this (or not). > > One obscure advantage of x64 installer projects is that they go into the > 64-bit Program Files folder and not the (x86) one. I just think this looks > nicer! > > I have a vague recollection that debugging 64-bit apps in Visual Studio > can be troublesome. Is that also true? > > *GregK* >
