Recommendations for Visual Studio 2010 solutions that contain both 'Any CPU' 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 '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: the 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?

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.