VS2017加载手动配置为x86的C++项目作为VS2010项目

Question

I just changed a vcxproj file (C++) to have x86 as a platform for all solution build configurations instead of Win32, which seems to be the default for all C++ projects. The project loads fine but it shows up as a VS 2010 project in solution explorer. Based on discussions with my coworkers, my underlying assumption is that Win32 is identical to x86, but is an old tag for the platform, and that it would be better to remove it and replace it with x86. I have looked online for similar questions, and while I did find similar issues, the suggestions didn't seem to help.

The chain of events that prompted making this change is that we are currently starting an effort to modernize our software and processes, and part of this is to prepare for our build process eventually getting pushed onto a virtual machine as I set up a smoke test for the development team. Unfortunately, we have been using devenv.exe on an instance of CruiseControl.NET to do our installer builds; so, for the smoke test I have been tasked with getting MSBuild to work on our software so we can use that directly and not have the full VS IDE loaded on the VM.

To my horror, I have slowly learned over the last couple months that VS and MSBuild are not consistent with each other. MSBuild without the guiding hand of VS will not honor a build order, and so will often build projects and try to link it's dependencies before building the dependencies. It will also fail when projects try to access the same resource rather than just blocking. These problems together have brought me to break apart our build by project in our CCNet script instead of just building the solution file.

The place where the particular flavor of the problem in question stems from, is that MSBuild will look in the project references and attempt to build those dependencies with the parent project's configuration and platform super-imposed upon them. It seems that C# projects have x86 as their default platform while C++ has Win32. Our software is a C#/C++/CLI Frankenstein monster, and having inconsistent project platforms is wreaking havoc on my efforts. MSBuild also appears to always try building our x86 platform projects with 2010 build tools for some odd reason. This fails as we don't have those installed and we shouldn't have to.

I made these changes directly to the xml in a separate text editor by duplicating all the Win32 property groups, changing the platform on the copy to x86, saving the file, switching the configuration for all builds in VS to the new x86 platform, saving the solution, and then removing the old Win32 property groups. This appears to work but I now see the C++ project marked with "Visual Studio 2010", which explains to me why MSBuild keeps trying to use 2010 build tools, but what would be the purpose for this?

In short the question is this: why is VS loading x86 platform projects as 2010 projects? Any insight is appreciated, keeping in mind that we are wedded to VS as our IDE and MSBuild as our build program, and we want to still have our local devenv building work. Our C++/CLI code is all going to be rewritten to C# and we are moving from CCNet in the future, but we would like this to work with what we have right now.

Answer 1

If you modified your .vcxproj Platform references to "x86", it won't work and is an "unknown platform" as far as Visual C++ is concerned. The actual 32-bit Platform name is "Win32" and has been for ages.

Only the "solution" system was updated to handle "x86" as an alias for "Win32".

TL;DR: Revert your changes to your vcxproj files. You can modify the SLN to call it "x86" instead of "Win32" in the combobox if you want.

    GlobalSection(SolutionConfigurationPlatforms) = preSolution
        Debug|x86 = Debug|x86
        Debug|x64 = Debug|x64
        Release|x86 = Release|x86
        Release|x64 = Release|x64
    EndGlobalSection
    GlobalSection(ProjectConfigurationPlatforms) = postSolution
        {guid}.Debug|x86.ActiveCfg = Debug|Win32
        {guid}.Debug|x86.Build.0 = Debug|Win32
        {guid}.Debug|x64.ActiveCfg = Debug|x64
        {guid}.Debug|x64.Build.0 = Debug|x64
        {guid}.Release|x86.ActiveCfg = Release|Win32
        {guid}.Release|x86.Build.0 = Release|Win32
        {guid}.Release|x64.ActiveCfg = Release|x64
        {guid}.Release|x64.Build.0 = Release|x64
    EndGlobalSection