Recommendations for Visual Studio 2010 solutions that contain both 'Any CPU' and 'x86' projects_问答_开发者

It often happens that a single C# solution contains some projects that are x86-specific (usually by having native dependencies) and others that are 'Any CPU'.

Up until recently I've always gone into the configuration manager and made sure that the solution platform was 'Any CPU'. This isn't too much of a problem; it requires occasional tweaks like the ones mentioned here, but overall isn't too bad.

However, I recently started wondering if these efforts are misguided. I'm clearly going against the way Visual Studio 2010 (and previously Visual Studio 2008) is designed to handle this. "Mixed Platforms" is actually an accurate description, and although it initially feels like there's something wrong, upon further thought I have to conclude that it's no more wrong than "Any CPU".

So, lately I have been trying to choose between keeping "Mixed Platforms" or changing to "x86" as my Solution Platform in such cases. The latter reflects the intention: t开发者_如何转开发he final EXE file is x86, and runs in 32-bit mode on 64-bit OSes. The former however is what Visual Studio really wants it to be.

In your experience, is there a particular solution platform that is more suitable in any way than the others in this situation?

Note 1: in every case that I've encountered, 'x86' is justified by native dependencies and 'Any CPU' is justified by being an external library that is really platform-independent.

Note 2: if I understand correctly, the solution platform doesn't make much of a difference; it's just a name. It seems to change the default "to-build-or-not-to-build" checkbox state when new projects are added, but that's about the only effect that it has. Right?

Ad Note 2: Yes. Solution platform is only a name for the set of project configurations, including whether to build or not a particular project.

I personally use x86 on all desktop applications (desktop because these are deployed on end users machines you usually have little control over - this is much easier if you are deploying a server application to a known server).

Reasons:

x86 allows easier debugging - edit and continue is not supported when running in 64 bit mode.
You can never anticipate when in the future you will add a reference to an assembly that requires x86 and forget to test properly on 64 bits, yielding embarrassing runtime errors on 64 bit deployments.

I have only configured my startup Windows Forms app as "x86" and all class librarys in the project as AnyCPU. If I execute the app all unmanaged dependencies, even from class librarys that are x86 still work.

Now If I add a class library that hasn't x86 dependencies from my project to another app that is configured as AnyCPU it works out-of-the-box.

Before I did that all my librarys where x86 and I got an exception if I wanted to use them in a 64 bit project.

From my point of view that's the best solution.

Yes, this is a bit of a mess you'll get into when you let the VS2010 project converter import a project from a previous version. Who doesn't. The old IDEs used Debug|Any CPU and Release|Any CPU as the default configuration names. VS2010 really prefers setting the Platform Target to x86 because the IDE works so much better when you do. And uses Debug|x86 and Release|x86 as the default configuration names.

Which produces the mix when you import an old project. And an extra set of configurations (mixed platforms) you didn't ask for to deal with the mess. Yuck. You cannot remove them either, the Remove button is disabled in the Configuration Manager.

These are just names btw that are not actually representative for the Platform Target setting. You can change the setting, it doesn't magically change the configuration name. Yuck.

You cannot fix this in the IDE. You'd have to edit the .sln and the .vcproj files to get rid of the extra configurations and edit the names of the ones you want to keep. Or just keep "Mixed Platforms" as your default configuration and ignore the rest. Just set the Platform Target to what you need, it doesn't have to match the configuration name.

Having had some more experience with this, here's what I now think:

It doesn't make any difference at all what the solution platform is called for a mixed-platform project. The behaviour of VS is exactly the same, requiring the exact same amount of clean-up after adding a project.
"Mixed platforms" is slightly more accurate, so I have a slight preference for this one.

Changing everything to x86 is undesirable for two reasons:

Some algorithms are almost twice as fast in x64 mode.
Any shared library that is x86 cannot be used in a project that benefits a lot from x64 mode.
Maintaining shared libraries in two platforms, x86+x64, is a lot more effort than keeping them "Any CPU" and cleaning up after Visual Studio every time it sprinkles unwanted solution configurations into a solution.