Visual Studio and .NET Framework Home
New C# Console application targets x86 by default
5/20/2009 8:21:41 PM
User(s) can reproduce this bug
When creating a new Visual C# Console Application in VS2010 for .NET 4.0, the default target settings for the project is to target the x86 platform instead of Any CPU (MSIL) like Visual Studio 2008 does
Visual Studio 2010 Beta 1
Windows Server 2008
Operating System Language
Steps to Reproduce
- Launch Visual Studio 2010
- Create a new C# Console Application (File -> New Project -> C# Console Application)
- After the project is created, open the project settings
- Select the Build tab in the project settings dialog
- Notice that the Platform Target listbox has x86 selected by default
- The default platform should be Any CPU. For most projects, this is a better option. It's also the behavior of the project templates in Visual Studio 2008.
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 2/8/2010 at 1:26 PM
Thanks to everyone for your comments. I'd like to encourage you to read Rick Byer's blog post, which you can find here: http://blogs.msdn.com/rmbyers/archive/2009/06/08/anycpu-exes-are-usually-more-trouble-then-they-re-worth.aspx. The post outlines the pros/cons that were considered in more detail.
If you are running into product bugs that are caused by this change, please file a separate Connect bug as this will help us better keep track of and address the issue.
on 2/6/2010 at 4:35 AM
Just hit this, with an additional twist: VS would not allow be to create a AnyCPU target for the project because elsewhere in the solution there was a class library.
Ended up editing the .csproj by hand, removing the "Multiple" and "x86" targets from the solution and ensuring the solution build configurations had the console application being built as AnyCPU.
Hardly an obvious approach.
Only including x86 target for .exe projects is easy to fix, *until* you add something that already targets AnyCPU, and then it gets very hard. Which could be the case when you create the .exe traget (e.g. a multiple exe solution with shared class library).
Overall this x86 only choice leads to having to create your own project templates to avoid pain down the development track when someone notices the platform is wrong.
on 1/25/2010 at 1:57 AM
I think consistency between the defaults is important. Keep it on Any CPU but make it more easily and quickly apparent what are the "as of now" negatives to using Any CPU so the user can make an informed choice of switching i if necessary!
on 1/22/2010 at 8:13 AM
I agree this is a bad decision. Many people will not even notice that it is x86 until it is a problem, leading them astray in the meantime. Projects should be consistent, this one is not. If EnC doesn't work with x64 then it should complain when someone tries to use it rather than trying to avoid the problem with inconsistency.
on 11/17/2009 at 2:32 PM
My vote for default AnyCPU!
AnyCPU is major benefit of .NET - building platform independent apps. Edit & Continue is major benefit of Visual Studio.
Is it possible to force AnyCPU application to run as 32bit process when being started from VS?
Bets solution is of course Edit & Continue for 64 bit apps. But in the meantime there should be Edit & Continue for Any CPU apps when running as 32 bit process on 64 machine. Maybe some switch in VS config if Any CPU apps will run as 32 or 64.
BTW: Looking at Beta 2 memory consumption, it will not take so long time and Visual Studio IDE itself will have to be 64bit :-).
on 11/13/2009 at 5:55 AM
> This is an intentional change we made for the Beta to gather feedback, knowing that it would be controversial...
From the overwhelmingly clear feedback on this, has the team come to any conclusions?
Almost everyone I've spoken to about this is complely outraged by this decision. Acutally, the first reaction tends to be total surprise, as this has been kept very quiet. If this change had been specifically highlighed in the blogs where the beta releases have so far been anounced, along with the lists of feature changes, you'd have a mob on your hands.
If you intend to keep your heads buried in the sand, be prepared to be cornered by a lot of displeased devs at the PDC.
on 6/15/2009 at 11:08 AM
Changing the default is a dreadful hack to the 64-bit E&C issue. Instead, VS should have the default be Any CPU, and then use a pop-up message box if the user attempts E&C indicating that they can enable E&C by changing the project setting.
The change to "x86" makes me wonder whether you guys really thought this through or not. You are basically subverting one of the major benefits of .NET - running on both 32- and 64-bit - in order to avoid some short-term pain that could be solved through more sophisticated UX guidance in VS itself (not to mention actually "fixing" the underlying issues).
on 6/9/2009 at 5:17 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:27 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 email@example.com as I’d like to hear more about your scenarios that are being impacted by this change.
C# IDE, Program Manager
on 5/22/2009 at 4:42 AM
Thanks for the feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.
Visual Studio Product Team
on 5/21/2009 at 6:41 AM
While I agree that this should not be the case, I believe this was done to give 64-bit users Edit & Continue support.
on 5/21/2009 at 4:22 AM
Defaulting to x86 is a dreadful decision. If it defaults to x86 then that's you're application stuck on that architecture forever. Even worse, if you're producting libraries or controls for use by third parties, then your x86 default locks them into the same architecture.
I'm on a 32 bit work machine at the moment so can't check - is Edit and Continue still not supported under x64 in VS2010? If so that's absolutely shocking.
on 5/20/2009 at 9:05 PM
I'm not sure if I agree with that, I find that it is better to have the project set to x86 because then edit and continue works, so if it's x86 out of the box I wouldn't complain.
to post a workaround.
Please enter a workaround.
on 11/17/2009 at 2:43 PM
I have not tested this workaround, but it shall work.
When VS is not running
1) Go to c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplates directory.
2) Navigate to project template you want change e.g. CSharp\Windows\1033\ConsoleApplication.zip
3) Extract *.csproj/*.vbproj file from it
4) Edit it in your favorite XML editor - replace all ocurrences of x86 with AnyCPU
5) Save and repack the zip
6) Delete corresponding file directory from c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ProjectTemplatesCache
This changes defaults for given project type.
on 6/15/2009 at 11:11 AM
Change the project settings to "CPU Type" after every new project you create, for as long as you use Visual Studio.
© 2014 Microsoft