VS2017 将手动配置为 x86 的 C++ 项目加载为 VS2010 项目
VS2017 loads C++ project that was manually configured to x86 as a VS2010 project
我刚刚更改了一个 vcxproj 文件 (C++)，将 x86 作为所有解决方案构建配置的平台，而不是 Win32，这似乎是所有 C++ 项目的默认平台。该项目加载正常，但它在解决方案资源管理器中显示为 VS 2010 项目。根据与同事的讨论，我的基本假设是 Win32 与 x86 相同，但它是平台的旧标签，最好将其删除并替换为 x86。我在网上查找了类似的问题，虽然我确实找到了类似的问题，但这些建议似乎没有帮助。
促使进行此更改的一系列事件是，我们目前正在努力使我们的软件和流程现代化，其中一部分是为我们的构建流程做准备，最终按照我的设置将其推送到虚拟机上为开发团队进行冒烟测试。不幸的是，我们一直在 CruiseControl.NET 的实例上使用 devenv.exe 来进行安装程序构建；因此，对于冒烟测试，我的任务是让 MSBuild 在我们的软件上运行，这样我们就可以直接使用它，而不是在 VM 上加载完整的 VS IDE。
令我震惊的是，在过去的几个月里，我慢慢了解到 VS 和 MSBuild 彼此不一致。没有 VS 指导的 MSBuild 不会遵守构建顺序，因此通常会构建项目并在构建依赖项之前尝试 link 它的依赖项。当项目试图访问相同的资源而不仅仅是阻塞时，它也会失败。这些问题共同促使我在 CCNet 脚本中按项目分解我们的构建，而不仅仅是构建解决方案文件。
所讨论问题的特殊之处在于，MSBuild 将查看项目引用并尝试使用父项目的配置和强加于它们的平台来构建这些依赖项。似乎 C# 项目将 x86 作为其默认平台，而 C++ 具有 Win32。我们的软件是 C#/C++/CLI Frankenstein 怪物，不一致的项目平台对我的工作造成了严重破坏。出于某种奇怪的原因，MSBuild 似乎也总是尝试使用 2010 构建工具构建我们的 x86 平台项目。这失败了，因为我们没有安装那些，我们不应该安装。
我在单独的文本编辑器中直接对 xml 进行了这些更改，方法是复制所有 Win32 属性 组，将副本上的平台更改为 x86，保存文件，切换配置对于 VS 中的所有构建到新的 x86 平台，保存解决方案，然后删除旧的 Win32 属性 组。这似乎可行，但我现在看到标有“Visual Studio 2010”的 C++ 项目，这向我解释了为什么 MSBuild 一直尝试使用 2010 构建工具，但这样做的目的是什么？
简而言之，问题是：为什么 VS 将 x86 平台项目加载为 2010 项目？任何见解都会受到赞赏，请记住我们将 VS 作为我们的 IDE 和 MSBuild 作为我们的构建程序，并且我们仍然希望我们的本地 devenv 构建工作。我们的 C++/CLI 代码都将被重写为 C#，并且我们将来会从 CCNet 转移，但我们希望它能与我们现在拥有的一起工作。
如果您将 .vcxproj 平台引用修改为“x86”，它将不起作用，并且就 Visual C++ 而言是一个“未知平台”。实际的 32 位平台名称是“Win32”并且已经存在了很长时间。
仅更新了“解决方案”系统以处理“x86”作为“Win32”的别名。
TL;DR: 还原对 vcxproj 文件的更改。如果需要，您可以修改 SLN 以在组合框中将其称为“x86”而不是“Win32”。
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
我刚刚更改了一个 vcxproj 文件 (C++)，将 x86 作为所有解决方案构建配置的平台，而不是 Win32，这似乎是所有 C++ 项目的默认平台。该项目加载正常，但它在解决方案资源管理器中显示为 VS 2010 项目。根据与同事的讨论，我的基本假设是 Win32 与 x86 相同，但它是平台的旧标签，最好将其删除并替换为 x86。我在网上查找了类似的问题，虽然我确实找到了类似的问题，但这些建议似乎没有帮助。
促使进行此更改的一系列事件是，我们目前正在努力使我们的软件和流程现代化，其中一部分是为我们的构建流程做准备，最终按照我的设置将其推送到虚拟机上为开发团队进行冒烟测试。不幸的是，我们一直在 CruiseControl.NET 的实例上使用 devenv.exe 来进行安装程序构建；因此，对于冒烟测试，我的任务是让 MSBuild 在我们的软件上运行，这样我们就可以直接使用它，而不是在 VM 上加载完整的 VS IDE。
令我震惊的是，在过去的几个月里，我慢慢了解到 VS 和 MSBuild 彼此不一致。没有 VS 指导的 MSBuild 不会遵守构建顺序，因此通常会构建项目并在构建依赖项之前尝试 link 它的依赖项。当项目试图访问相同的资源而不仅仅是阻塞时，它也会失败。这些问题共同促使我在 CCNet 脚本中按项目分解我们的构建，而不仅仅是构建解决方案文件。
所讨论问题的特殊之处在于，MSBuild 将查看项目引用并尝试使用父项目的配置和强加于它们的平台来构建这些依赖项。似乎 C# 项目将 x86 作为其默认平台，而 C++ 具有 Win32。我们的软件是 C#/C++/CLI Frankenstein 怪物，不一致的项目平台对我的工作造成了严重破坏。出于某种奇怪的原因，MSBuild 似乎也总是尝试使用 2010 构建工具构建我们的 x86 平台项目。这失败了，因为我们没有安装那些，我们不应该安装。
我在单独的文本编辑器中直接对 xml 进行了这些更改，方法是复制所有 Win32 属性 组，将副本上的平台更改为 x86，保存文件，切换配置对于 VS 中的所有构建到新的 x86 平台，保存解决方案，然后删除旧的 Win32 属性 组。这似乎可行，但我现在看到标有“Visual Studio 2010”的 C++ 项目，这向我解释了为什么 MSBuild 一直尝试使用 2010 构建工具，但这样做的目的是什么？
简而言之，问题是：为什么 VS 将 x86 平台项目加载为 2010 项目？任何见解都会受到赞赏，请记住我们将 VS 作为我们的 IDE 和 MSBuild 作为我们的构建程序，并且我们仍然希望我们的本地 devenv 构建工作。我们的 C++/CLI 代码都将被重写为 C#，并且我们将来会从 CCNet 转移，但我们希望它能与我们现在拥有的一起工作。
如果您将 .vcxproj 平台引用修改为“x86”，它将不起作用，并且就 Visual C++ 而言是一个“未知平台”。实际的 32 位平台名称是“Win32”并且已经存在了很长时间。
仅更新了“解决方案”系统以处理“x86”作为“Win32”的别名。
TL;DR: 还原对 vcxproj 文件的更改。如果需要，您可以修改 SLN 以在组合框中将其称为“x86”而不是“Win32”。
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