Howto save the Target Platform in a VisualStudio Solution (with version control and testing in mind)

Question

Visual Studio (at least VisualStudio 2010) stores the target platform settings in the *.suo file which obviously shall not be version controlled.

In my case this is no problem for the central build because that uses a command line option on msbuild that force the target platform to be x86 as required.

However, if a colleague checks out my project he will always end up building for AnyCPU and testing that. Because he has no *.suo file VisualStudio will use the default settings.

Bad or not, the colleague is obliged to test for x86.

Is there an easy way to safely persist the target platform for a Solution? An environment variable forcing the default is not exactly what we need but would be good enough and easy enough.

Answer 1

Visual Studio ... stores the target platform settings in the *.suo file

It doesn't, it stores it in the project file. A relevant snippet from one I created:

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <PlatformTarget>x86</PlatformTarget>
    // etc...
  </PropertyGroup>

It is configured with Project + Properties, Build tab, Platform target combo box. Repeat for the Release configuration. Only the setting on the EXE project matters, that's the one that determines the bitness for the process. DLLs have no choice and ought to use AnyCPU.

---

In all likelihood you are being tripped up by a rather drastic design mistake in VS2010. Another item is the solution platform name, prominently displayed in the Build + Configuration Manager dialog for example. This was always AnyCPU for managed projects, VS2010 screwed this up royally by renaming the default to "x86". And creating a big old mess of it when you import projects from earlier versions, yielding a "Mixed platforms" configuration. And yes, the last selection is saved in the .suo file.

This is irrelevant to managed projects, it only matters to C++ projects. Where the setting selects a different set of build tools. The 64-bit compiler and linker are different programs. A non-existing issue for managed projects, bitness is determined at runtime by the jitter selection and you use the exact same C# compiler regardless of the desired platform target.

The best way to eliminate these kind of mistakes is by aggressively deleting platforms and only keeping one. Use Build + Configuration Manager, select the "Edit" entry in the upper-right combo box and click Remove for extraneous platforms until you only have AnyCPU left. Updating your VS version is also recommended, this mistake was corrected again in VS2012.