Recommendations for VS2010 solutions that contain both AnyCPU and x86 projects

Question

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

Up until recently I've always gone into the configuration manager and made sure that the solution platform was AnyCPU. 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 VS2010 (and previously 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: the final exe 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 AnyCPU 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?

Answer 1

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:

1. x86 allows easier debugging - edit and continue is not supported when running in 64 bit mode.
2. 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.

Answer 2

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.

Answer 3

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.