2
votes

When Configuration Manager (or the appropriate boxes in the toolbar) has x64 Release and the Properties Build has x86 Debug (Without 'Active') and F5 is clicked - VS follows Configuration Manager. So what is Properties Build for?

Edit:

This always determines the action:

enter image description here

This never does even if it's not set to 'Active' :

enter image description here

Checked with the following code:

        public Form1()
        {
            InitializeComponent();
#if (DEBUG)
            Text = "DEBUG";
#else
            Text = "Release";
#endif
            Text += Environment.Is64BitProcess;
        }

With Configuration Manager set to Debug+x86 (despite being an x64 computer), and the Build-tab under the project's properties set to Release+x64 (Not 'Active'). The result was: "DEBUGfalse".

So what is the latter (the Build tab) for?

1

1 Answers

3
votes

It simply lets you skip building a project in that particular configuration by unticking it. Necessary if the project cannot or should not be built in that configuration. This is a pretty rare thing to do but can be useful if, say, you only want to build an installer in the Release build or have a project that cannot be built in the configuration.

The notion of having distinct platforms is important to unmanaged code, very unimportant to managed code. Since managed code is naturally oblivious to the target architecture, the jitter takes care of it at runtime. The name of the Platform also has nothing to do with the architecture the program can run in, the only setting that matters is Project + Properties, Build tab, Platform target setting. And only for an EXE project. Having a mismatch between that setting and the solution's Platform name has bewildered VS2010 users deeply.

The only sane setup for a managed solution is to have only one solution platform named AnyCPU. The way it was done in VS versions prior to VS2010. You'd only ever consider adding platforms when you build unmanaged code.