AnyCPU Exes are usually more trouble than they're worth

re: AnyCPU Exes are usually more trouble than they're worth

Ethan — Wed, 03 Nov 2010 21:26:19 GMT

This breaks SharePoint development, since all SharePoint 2010 bits are built 64bits.

re: AnyCPU Exes are usually more trouble than they're worth

Simon Cooper — Wed, 18 Aug 2010 09:35:31 GMT

For those interested, I've figured out how you can change it back - www.simple-talk.com/.../94124.aspx

re: AnyCPU Exes are usually more trouble than they're worth

Simon Waterer — Sun, 15 Aug 2010 23:40:03 GMT

I'll just share an issue I had upgrading a VS2008 project to VS2010 relating to AnyCPU exe's and COM Interop assemblies.

The project was created in VS2008 as an AnyCPU exe and referenced the "Windows Script Host Object Model" COM library, which causes the Interop.IWshRuntimeLibrary.dll assembly to be generated at compile time. With VS2008 all was well running on both x86 and x64 platforms.

After upgrading the project to VS2010 the project appeared to remain targeted to the AnyCPU platform but it would encounter a BadImageFormatException when run on x64 platforms at the point of loading the Interop.IWshRuntimeLibrary.dll assembly. The exception did not occur on x86 platforms.

I eventually tracked down the problem by creating a new project afresh in VS2010 and diffing the .csproj files until I found that the freshly created VS2010 project file had a <PlatformTarget>AnyCPU</PlatformTarget> element present within the <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">...</PropertyGroup> and <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">...</PropertyGroup> elements, whereas the project upgraded from VS2008 to VS2010 did not define the <PlatformTarget>AnyCPU</PlatformTarget> element at all.

I've been able to reproduce this issue several times, every time it appears that the VS2008 to VS2010 upgrade does not place the <PlatformTarget>AnyCPU</PlatformTarget> element in the .csproj file.

I'm guessing here that the BadImageFormatException arose because the C# compilation target in MSBuild uses the Platform property (which was correctly left at AnyCPU during the upgrade) as the platform target, whereas the COM reference generation target in MSBuild uses the PlatformTarget property, and since it was not defined after the upgrade it defaulted to x86. There was no problem earlier with VS2008 because it would have defaulted to AnyCPU.

What misled me about this was that the VS2010 GUI was displaying Any CPU in the dropdown for Platform target under the project property pages. It wasn't until I changed it to x86 or x64 (i.e. something other than Any CPU), saved the project, then changed it back to Any CPU, and saved the project again did the <PlatformTarget.../> element appear in the project file.

re: AnyCPU Exes are usually more trouble than they're worth

SamC — Wed, 11 Aug 2010 01:00:43 GMT

I'm staggered at the attitude of "let's not do anything".

1. Test and fix issues. Software always has bugs anyway. Test on a 64-bit platform. Everyone has one now.

2. Who cares that you lose a few percent performance? > 2GB memory available for processes on 64-bit. More and more applications will NEED this.

3. People like you are the REASON the tools haven't been made yet. Microsoft are using YOUR BLOG as an example of reason to JUSTIFY not doing anything. See Microsoft Connect ID 431200.

Your points are irrelevant to future (and some current) application requirements.

re: AnyCPU Exes are usually more trouble than they're worth

Rick Byers - exMSFT — Fri, 06 Aug 2010 23:25:07 GMT

I should also add: I think a core part of the problem here is the diagnostics experience for BadFormatException. Would it have helped if you got at least a more precise error message here? Something like "BadFormatException: Attempt to load an x86-only DLL 'path\foo.dll' into a 64-bit process"? That would be a GREAT feature suggestion for the CLR, and I'd be happy to talk to some people here to see if we can get that done for CLR 4.5.

re: AnyCPU Exes are usually more trouble than they're worth

Rick Byers - exMSFT — Fri, 06 Aug 2010 23:13:07 GMT

Jesper, I'm sorry to hear you've had this trouble. Just to make sure I understand your scenario: you created an EXE project in VS2010 (which is set to x86), and then later changed it to a build as a class library instead, but didn't realize that it was buiding as an x86-only class library? I agree that's a nasty trap to fall into - it would have been nice if we thought to add a warning in that case suggesting the user may want to change the platform as well.

That said, this is far from an issue of "a product that crashes vs. Edit & Continue support". As I mention above, by far the strongest reason for this change is about reliability of testing and consistent behavior. I'd bet you prefer having your applicaiton crash reliably and quickly whenever you test it on a 64-bit machine, then having one that seems to work OK but occasionaly causes weird problems for your customers on 64-bit machines. The bottom line is that if you really want your application to switch automatically between running as a 32-bit and 64-bit process, that's an important decision - and one we think you should make intentionally with knowledge of the implications it has for your testing and deployment.

re: AnyCPU Exes are usually more trouble than they're worth

Jesper — Fri, 06 Aug 2010 22:48:36 GMT

why thank you. I just spent hours debugging a crash: a BadImageFormatException in kernelbase.dll apparently. Turns out to be because of your little shortcut to make Edit&Continue work by default on 64-bit machines. One of our libraries had been set to x86 because of it, and our Any CPU process running on a 64-bit machine apparently didn't like that. Setting everything consistently to Any CPU fixed it.

So, when changing this default, it didn't occur to anyone that some users might not create every project anew in VS2k10, and let its output type stay fixed forever? People importing a project from VS2008 get a nice AnyCPU process. And if you dare change the output type of an executable project to Class Library, you get a x86 .dll. And if you try to load that into your AnyCPU process on a 64-bit machine, hilarity ensues.

Yes, I can understand the thinking behind this decision, but it seems like no one spent as much as 5 minutes thinking about the negative consequences of this change. I don't know about everyone else, but I prefer a product that doesn't crash over Edit & Continue support.

re: AnyCPU Exes are usually more trouble than they're worth

Rick Byers - exMSFT — Thu, 03 Jun 2010 19:54:04 GMT

Andreas,

The EXE for the process must have the LARGEADDRESSAWARE bit set in it's header. If it's a .NET EXE then you need to use the 'editbin' tool after it's created to set this bit (see here). Is seems the managed compilers have chosen not to make this an option due to concerns over some DLLs you may load that don't support LAE (see here). I've added these links and softened my guidance above to account for this. Thanks for bringing this up.

Rick

re: AnyCPU Exes are usually more trouble than they're worth

Andreas M. — Thu, 03 Jun 2010 19:26:09 GMT

Thank you for this detailed clarification on the subject. You say "The first thing that should usually be done to such programs is to have them opt-into 4GB mode so that they can get a full 4GB of address space when running in the WOW on a 64-bit OS". Can you point me to an MSDN article or something that explains how this is to be done? Thanks in advance!

re: AnyCPU Exes are usually more trouble than they're worth

Rick Byers - exMSFT — Thu, 27 May 2010 19:57:57 GMT

Thomas,

DLLs produced by VS2010 are AnyCPU by default and so you shouldn't have any trouble there. EXEs are x86 by default and so won't load for EXECUTION in a 64-bit process (eg. Assembly.Load/LoadFrom will fail). But if you're just loading an EXE for inspection purposes, Assembly.ReflectionOnlyLoad should be able to load it for you - even if it isn't compatible with your processes bitness (and you should be using ReflectionOnlyLoad anyway if you don't want to execute anything from the assembly).

Hope this helps,

Rick