7

I recently started a new job, and one of the first things I noticed everybody talking about was "updating" All our .NET apps to x64. I initially thought this odd since we all know .NET compiles to platform agnostic IL and the specific CLR runs the code.

Looking a bit further, I found this helpful article and this SO post which helped explain things.

So now I understand that the IL isn't changed, only meta data basically saying to run in WOW64 or not on a x64 system (in a nutshell).

So if I'm on a x64 system, I can specify "Any CPU" to run natively, but won't support 32bit dlls; I can specify "x86" which will support 32bit dlls (since they both would be running under WOW64); but when would I specify "x64"? It seems that 64bit dlls would be supported in the "Any CPU" scenario on a x64 system. Is this if I want to prevent someone from running my app on a 32bit system or ensuring failure when trying to load 32bit dlls?

It would also seem to me that you would only need to set it to something other than "Any CPU" if you have some 3rd party dll to worry about in your project. Is it best to leave it as "Any CPU" for every other project not dealing with others dlls?

If I do happen to set my target to "x86" because I have a 32bit 3rd party dll, is my application actually considered to be running in 64bit if on a 64bit system just under WOW64?

Community
  • 1
  • 1
earthling
  • 5,084
  • 9
  • 46
  • 90
  • 1
    You can't ignore it in your installer. If you have an x64 requirement then you must set the installer's TargetPlatform setting to x64. It won't install properly if you don't. Since the installer now already ensures that a 64-bit operating system is available, it now no longer matters what you select for your EXE project. Might as well use AnyCPU. – Hans Passant Dec 08 '11 at 20:33

2 Answers2

8

Yes, you would specify that the project should compile to x64 if you're calling a DLL that is itself 64 bit (either because it is native, or is a managed DLL that's itself calling a 64 bit native DLL, etc).

Likewise for specifying that it should be x86 if you're dealing with 32-bit 3rd party DLLs; it will not be considered a 64-bit application if running on a 64-bit version of Windows.

If you're just dealing with pure managed code, then I'd leave things as "any". I also generally leave DLLs as "any" as well, even if the executeable will be specified to be either x86 or x64.

And even if you're dealing with native dlls, you might still be able to get away with leaving it as "any" if you're using PInvoke; you can have two versions of a class that wraps around it, one for x86, one for x64, and choose which one to use at runtime by checking the IntPtr.Size property.

And of course, if you're application needs more than 4 GBs of RAM and you want to enforce that it has to run on a 64-bit OS, then you'll also need to target x64.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
The Grand User
  • 727
  • 4
  • 14
2

You would specify x64 if you're using native code through COM or P/Invoke that doesn't have a 32-bit version.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964