VS2017加载C++项目，它被手动配置为x86作为VS2010项目

我刚刚更改了VCXPROJ文件（C++），使X86作为所有解决方案生成配置的平台，而不是Win32，这似乎是所有C++项目的默认值。该项目加载良好，但在解决方案资源管理器中显示为VS 2010项目。根据与同事的讨论，我的基本假设是Win32与x86相同，但对于平台来说是一个旧标签，最好将其删除并用x86替换。我在网上寻找过类似的问题，虽然我确实发现了类似的问题，但这些建议似乎没有帮助

促使做出这一改变的一系列事件是，我们目前正在开始努力使我们的软件和流程现代化，其中一部分是为我们的构建流程做准备，最终在我为开发团队设置冒烟测试时将其推到虚拟机上。不幸的是，我们一直在CruiseControl.NET的实例上使用devenv.exe进行安装程序构建；因此，对于冒烟测试，我的任务是让MSBuild在我们的软件上工作，这样我们就可以直接使用它，而不必在VM上加载完整的VSIDE

令我恐惧的是，在过去的几个月里，我慢慢地了解到VS和MSBuild彼此不一致。没有VS指导的MSBuild将不会遵守构建顺序，因此通常会在构建依赖项之前构建项目并尝试链接其依赖项。当It试图访问相同的资源项目时，而不是试图访问相同的资源项目时。这些问题使我在CCNet脚本中分解了逐个项目的构建，而不仅仅是构建解决方案文件

所讨论问题的特殊风格来源于MSBuild将查看项目引用，并尝试使用父项目的配置和平台来构建这些依赖项。C++项目中有X86作为默认平台，而C++具有Win32。我们的软件是一个C#/C++/CLI的弗兰肯斯坦怪兽，而不一致的项目平台对我的工作造成了极大的破坏。出于某些奇怪的原因，MSBuild似乎总是尝试使用2010构建工具构建x86平台项目。这失败了，因为我们没有安装这些，我们不应该这样做

我在单独的文本编辑器中直接对xml进行了这些更改，方法是复制所有Win32属性组，将副本上的平台更改为x86，保存文件，将VS中所有内部版本的配置切换到新的x86平台，保存解决方案，然后删除旧的Win32属性组。这似乎起作用，但我现在看到的C++项目用“Visual Studio 2010“；，这向我解释了为什么MSBuild一直在尝试使用2010构建工具，但这样做的目的是什么

简而言之，问题是：为什么VS将x86平台项目加载为2010项目？任何洞察都是值得赞赏的，请记住，我们将VS作为IDE，将MSBuild作为构建程序，并且我们仍然希望有本地的devenv构建工作。我们的C++/CLI代码都将被重写为C#，未来我们将从CCNet迁移，但我们希望它能与我们现在拥有的一起工作。