Platform target is defaulting to x86 rather than Any CPU by Daniel Smith

I have this issue with Visual Studio 2010 but not 2008. Is if fixed for 2008 only?

Yet another item "closed" when it's not really fixed. Anyone else getting tired of this bull****? It's been what? 6-8 years since this was initially reported and it's STILL not fixed when their new OS is pushing 64-bit and the new server is 64-bit only?

I bought Windows 7 64-bit so I could start building and testing 64-bit applications. Without EnC the amount of time spent doing that goes through the roof. Switching to x86 to debug and use EnC is really unacceptable.

Change it back to Any CPU! You destroy one of the big advanteges of the .Net platform if you default to x86 here.

"Adding true support for EnC to the 64-bit CLR is unfortunately a large work item and other features were prioritized over this given the work around of changing the platform target to x86. However, as the vs2010 cycle progressed, we started getting more feedback about 64-bit EnC support (and other issues such as the P/Invoke problem mentioned earlier) as more users started switching over to 64-bit OS’s for development. Our expectation is that this trend will continue and cause even more pain for customers."
We are encountering this pain now. Should there be a connect ID for this issue?

Let's start moving in a coherent direction please. Support your x64 developers who are supporting your x64 platform!

(forgot to add , not only is X86 the default but the other build platforms are gone too so, if by any stretch of the immagination you decide that loosing X64 in favor of this isn't a big deal, please put the X64 and AnyCPU platforms back so it's just a matter of changing platform selection and not of having to re create the platform targets).

I totally think the default should remain AnyCpu, switching to 86 for edit and continue makes no sense. If you loose feature in AnyCPU vs x86 so be it but you're taking this the wrong way around , there is always the option of going to X86 manually if you need the added feature but the whole point of the .net platform is not generating specific code. If i missed this and ended up releasing X86 bloat in production and realised it afterward i'd be pretty angry! Beside i think the edit and continue warning telling you it's not supported in X64 is already enought of an indication and, to me , it's not an important feature.

Another vote for changing it back. After reading Rick Byers article I can understand the merits of x86, but I feel like we need to pay the price of moving to x64 now. Creating more x86 applications will increase the dependency on WOW at a time when we should strive for a pure x64 world, if only to allow the hardware a chance to move forward with x64 innovations faster.

I'd agree that this should be changed back. I do SharePoint development and for the first month or so I was not able to use VS 2010 because I couldn't get it work when I referenced Microsoft.SharePoint.dll. Since I have the x64 version of SharePoint the default target of x86 made all the calls to the SharePoint API fail.

Switch it back to Any CPU. Otherwise it becomes confusing when we tell folks that our .NET app doesn't care what bitness you run under and yet our .NET apps happen to be x86. .NET, and the default apps we create with it, should remain platform-agnostic. Don't change the default to fix a limitation in the tool.

I think the default of "x86" is terrible. Developers using .NET expect that their apps will run on either platform, and they will be very surprised and annoyed to learn their app is running under WOW on 64-bit Windows.

FYI - Rick Byers, a developer on the CLR, just posted a great blog entry going in depth about this topic. It'd be great to hear your feedback on it! (on either the blog itself or in this bug) Thanks!

--DJ

Hi danieldsmith,

Thanks for your feedback! This is an intentional change we made for the Beta to gather feedback, knowing that it would be controversial. To provide some context, the motivation for the change is to alleviate the pain that customers are feeling when developing on a 64-bit OS – some examples being Edit and Continue (EnC) and P/Invoke scenarios. To elaborate on the EnC example, EnC is supported on a 64-bit OS provided that you’re debugging a 32-bit process. However, by defaulting to AnyCPU, processes are automatically run as 64-bit, which means that EnC will not work unless you change the platform target to be x86.

Adding true support for EnC to the 64-bit CLR is unfortunately a large work item and other features were prioritized over this given the work around of changing the platform target to x86. However, as the vs2010 cycle progressed, we started getting more feedback about 64-bit EnC support (and other issues such as the P/Invoke problem mentioned earlier) as more users started switching over to 64-bit OS’s for development. Our expectation is that this trend will continue and cause even more pain for customers. Since doing the CLR work is extremely risky so late in the cycle, we opted to change the default target type to alleviate what we expect will be extremely serious pain in the next couple of years.

Given the feedback we’ve heard so far, it’s worth mentioning that we’re planning on changing the default target for Class Libraries to be AnyCPU for Beta2 so that libraries can be consumed in both 32-bit and 64-bit processes without any change. I’m going to resolve this bug as a duplicate of the internal bug we’re using to track this work, but please feel free to contact me at djpark@microsoft.com as I’d like to hear more about your scenarios that are being impacted by this change.

Thanks again,
DJ Park
C# IDE, Program Manager

Noticed this as well - I'd much rather it defaulted to "Any CPU" - it's a major feature of .NET!

Thanks for your feedback.

We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team