Visual Studio and .NET Framework Home
Platform target is defaulting to x86 rather than Any CPU
5/21/2009 4:05:18 AM
User(s) can reproduce this bug
The platform target for new projects (WinForms, WPF, console app etc.) is incorrectly defaulting to x86.
In all previous versions this is defaulted to the platform neutral "Any CPU" target. This is the ideal default as it doesn't limit your application to any specific platform.
Visual Studio 2010 Beta 1
Operating System Language
Steps to Reproduce
File > New Project > Choose any project type e.g. WPF Application.
Look at the platform drop down box on the toolbar.
The platform type is incorrectly defaulting to x86.
The platform type should default to Any CPU.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 11/3/2010 at 2:18 PM
I have this issue with Visual Studio 2010 but not 2008. Is if fixed for 2008 only?
on 9/22/2010 at 9:12 PM
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.
on 3/4/2010 at 8:58 AM
Change it back to Any CPU! You destroy one of the big advanteges of the .Net platform if you default to x86 here.
on 2/24/2010 at 10:19 PM
"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?
on 2/24/2010 at 10:05 PM
Let's start moving in a coherent direction please. Support your x64 developers who are supporting your x64 platform!
on 12/19/2009 at 12:49 PM
(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).
on 12/19/2009 at 12:48 PM
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.
on 10/30/2009 at 7:07 AM
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.
Tyler W Lamb
on 8/12/2009 at 6:48 AM
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.
on 7/6/2009 at 1:33 PM
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.
on 6/15/2009 at 11:03 AM
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.
on 6/9/2009 at 5:16 PM
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!
on 6/4/2009 at 6:26 PM
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 firstname.lastname@example.org as I’d like to hear more about your scenarios that are being impacted by this change.
C# IDE, Program Manager
Eric Bickle - BlueRealm
on 5/22/2009 at 10:09 AM
Noticed this as well - I'd much rather it defaulted to "Any CPU" - it's a major feature of .NET!
on 5/22/2009 at 1:04 AM
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.
Visual Studio Product Team
to post a workaround.
Please enter a workaround.
on 10/15/2010 at 1:28 PM
Goto C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates\CSharp\Windows\1033 and repackage ConsoleApplication.zip to default to what you want.
on 6/15/2009 at 3:30 PM
Change the project settings to "CPU Type" after every new project you create, for as long as you use Visual Studio.
© 2014 Microsoft