New C# Console application targets x86 by default by Tomas Restrepo

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.

Regards
DJ

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.

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!

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.

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 :-).

> 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.

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).

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 tomasr,

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

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.

Thank you,
Visual Studio Product Team

While I agree that this should not be the case, I believe this was done to give 64-bit users Edit & Continue support.

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.

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.