What AnyCPU Really Means As Of .NET 4.5 and Visual Studio 11

April 4, 2012

15 comments

The 32-bit and 64-bit development story on Windows seemingly never stops causing problems for developers. It’s been a decade since 64-bit processors have started popping up in the Windows consumer environment, but we just can’t get it right. If you forget some of the gory details, here are a couple of reminders:

  • On a 64-bit Windows system, both the 32-bit and 64-bit versions of system DLLs are stored. The 64-bit DLLs are in C:\Windows\System32, and the 32-bit DLLs are in C:\Windows\SysWOW64.
  • When a 32-bit process opens a file in C:\Program Files, it actually reads/writes to C:\Program Files (x86).
  • There are separate views of (most of) the registry for 32-bit and 64-bit applications. You can change the 64-bit registry location and it wouldn’t be visible to 32-bit applications.

These differences are hardly elegant as they are, but they allow 32-bit applications to run successfully on a 64-bit Windows system. While unmanaged applications always had to choose the native target—x86, x64, or ia64 in the Visual Studio case—managed code has the additional choice of AnyCPU.

What AnyCPU used to mean up to .NET 4.0 (and Visual Studio 2010) is the following:

  • If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
  • If the process runs on a 64-bit Windows system, it runs as a 64-bit process. IL is compiled to x64 machine code.
  • If the process runs on an Itanium Windows system (has anyone got one? ;-) ), it runs as a 64-bit process. IL is compiled to Itanium machine code.

Prior to Visual Studio 2010, AnyCPU was the default for most .NET projects, which was confusing to some developers: when they ran the application on a 64-bit Windows system, the process was a 64-bit process, which may cause unexpected results. For example, if the application relies on an unmanaged DLL of which only a 32-bit version is available, its 64-bit version won’t be able to load that component.

In Visual Studio 2010, x86 (and not AnyCPU) became the default for most .NET projects—but otherwise the semantics haven’t changed.

In .NET 4.5 and Visual Studio 11 the cheese has been moved. The default for most .NET projects is again AnyCPU, but there is more than one meaning to AnyCPU now. There is an additional sub-type of AnyCPU, “Any CPU 32-bit preferred”, which is the new default (overall, there are now five options for the /platform C# compiler switch: x86, Itanium, x64, anycpu, and anycpu32bitpreferred). When using that flavor of AnyCPU, the semantics are the following:

  • If the process runs on a 32-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
  • If the process runs on a 64-bit Windows system, it runs as a 32-bit process. IL is compiled to x86 machine code.
  • If the process runs on an ARM Windows system, it runs as a 32-bit process. IL is compiled to ARM machine code.

The difference, then, between “Any CPU 32-bit preferred” and “x86” is only this: a .NET application compiled to x86 will fail to run on an ARM Windows system, but an “Any CPU 32-bit preferred” application will run successfully.

To inspect these changes, I created a new C# console application in Visual Studio 11 that prints the values of Environment.Is64BitOperatingSystem and Environment.Is64BitProcess. When I ran it on my 64-bit Windows system, the result was as follows:

Is64BitOperatingSystem = True
Is64BitProcess         = False

Inspecting the project’s properties shows the following (in the current Visual Studio UI “Prefer 32-bit” is grayed out and unchecked, where in actuality it is enabled…):

image

Inspecting the executable with CorFlags.exe shows the following:

Version   : v4.0.30319
CLR Header: 2.5
PE        : PE32
CorFlags  : 131075
ILONLY    : 1
32BITREQ  : 0
32BITPREF : 1
Signed    : 0

After changing the 32BITPREF setting with CorFlags.exe (using the /32bitpref- option), the output was as follows:

Is64BitOperatingSystem = True
Is64BitProcess         = True


I am posting short updates and links on Twitter as well as on this blog. You can follow me:@goldshtn

Add comment
facebook linkedin twitter email

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

15 comments

  1. OlivierApril 4, 2012 ב 1:14 PM

    Great article! By the way, I really miss the VS2008 behavior that defaulted to Any Cpu for all types of projects… I like being able to set the configuration by myself (and I hate those Mixed platforms being generated)! Seems it’ll be the case with VS11

    Reply
  2. Richard ThorneApril 5, 2012 ב 3:27 AM

    I assume the “Prefer 32bit” box not being checked is a bug in VS? Otherwise this is distinctly unintuitive and backwards :-/

    Reply
  3. Adam GravesApril 5, 2012 ב 4:32 PM

    Don’t you have this backward?

    On a 64-bit Windows system, both the 32-bit and 64-bit versions of system DLLs are stored. The 64-bit DLLs are in C:\Windows\System32, and the 32-bit DLLs are in C:\Windows\SysWOW64.

    Reply
  4. SpringyApril 5, 2012 ב 6:52 PM

    So without the use of CorFlags.exe all my AnyCPU applications which REALLY need to be able to consume more than 3 GB of RAM when run on adequate hardware will out of a sudden stop working as expected?

    I hope Microsoft will introduce an option on the “Compatibility” tab (Explorer -> EXE -> Properties) which allows to overwrite both an existing and a non-existing 32BITPREF flag: Forcing a 32BITPREF=1 app to run on 64-bit anyways or forcing an old AnyCPU app to run as 32-bit, just as .NET4-x64 would have been uninstalled.

    Reply
  5. Sasha GoldshteinApril 9, 2012 ב 12:30 PM

    @Richard: Yes, I think it’s a bug.

    @Springy: I haven’t tested it, but I think that when you convert an existing AnyCPU project to .NET 4.5 it will retain the original AnyCPU behavior. If you stay with .NET 4.0 it will be the old AnyCPU behavior anyway.

    @Adam: No, unfortunately it’s Microsoft that have it backwards :-) Mainly for compatibility reasons. SysWOW64 is named after “Windows on Windows 64″, which is the layer that allows 32-bit processes to run on 64-bit Windows.

    Reply
  6. Object SynergyApril 10, 2012 ב 3:51 PM

    Its true. I assume the “Prefer 32bit” box not being checked is a bug in VS? Otherwise this is distinctly unintuitive and backwards :-/

    Reply
  7. Noam ShefferApril 19, 2012 ב 9:59 AM

    There is more,
    When AnyCPU application is located under “C:\Program Files” the loader will start the x64 CLR and when located under “C:\Program Files (x86)” it will start as x86

    Reply
  8. AceHackJune 4, 2012 ב 8:59 PM

    Their is one thing you forgot to mention about the difference between x86 and AnyCPU 32-bit perferred. When hosted in IIS and the app pool “Enable 32-bit Applications” is disabled then a x86 app will fail to run but a AnyCPU 32-bit perferred app will run in 64-bit mode. Thanks.

    Reply
  9. zfJune 12, 2012 ב 2:29 PM

    With the strategy of defaults x86 in VS2010 and 32b-preferred in VS2012 Windows for PCs are going to be never free from the burden of 32bit apps backward compatibility.

    This is going to be insane in perspective of 5-10 years, such as is taking care of 16-bits apps nowdays.

    Reply
  10. Pablo MontillaOctober 18, 2012 ב 2:04 AM

    It would appear that 32 bit required can only be applied to EXEs and not to DLLs. That’s why you see the checkbox grayed out.

    Reply
  11. Sasha GoldshteinOctober 24, 2012 ב 8:01 AM

    @Pablo: This was a console application (so an EXE). However, this bug was fixed in RTM.

    Reply
  12. WoodyOctober 31, 2012 ב 9:49 PM

    @Sasha Goldshtein in re: @Pablo

    If a Windows Forms Applications first built as x86 then changed to AnyCPU, the Prefer 32-bit checkbox remains grayed out.

    Reply
  13. Shaun WilsonAugust 8, 2013 ב 1:21 PM

    Ridiculous. I’m trying to figure out what happened to Microsoft in the last 3-6 years that bad ideas like this are made possible. You know what you should have done, instead? Made it possible to bind to both 32bit and 64bit assemblies and resolve PA at run-time, instead of this retarded scat. For the first time in over 20 years I’m actually angry at Microsoft out of principal: this is unnecessary, this complicates a simple thing, this does not address ANY problems, there are REAL problems with cross-platform builds which still need to be addressed. Ridiculous. If anyone thinks this was a good idea, I beg you to find a new career/hobby, please.

    Reply
  14. DaveOctober 31, 2013 ב 12:19 PM

    Personally I think it is horrible they set this by default with no Tools setting to turn it off. Even worse, you can’t search for it since not in the csproj files unless turned off! Probably added because of the Office Automation incompatibilities with CPUAny on a x64 machine with most folks installing 32 bit Office.

    Reply
  15. DaveOctober 31, 2013 ב 12:46 PM

    So bottom line is they took a confusing process that everyone was finally getting used to and made it more confusing all over again…

    Reply