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

Posted 2023-03-22

【中文标题】VS2017 将手动配置为 x86 的 C++ 项目加载为 VS2010 项目

【英文标题】：VS2017 loads C++ project that was manually configured to x86 as a VS2010 project

【发布时间】：2021-12-18 04:57:36

【问题描述】：

我刚刚更改了一个 vcxproj 文件 (C++)，以将 x86 作为所有解决方案构建配置的平台，而不是 Win32，这似乎是所有 C++ 项目的默认设置。该项目加载正常，但它在解决方案资源管理器中显示为 VS 2010 项目。根据与同事的讨论，我的基本假设是 Win32 与 x86 相同，但它是该平台的旧标签，最好将其删除并替换为 x86。我在网上查找了类似的问题，虽然我确实找到了类似的问题，但这些建议似乎没有帮助。

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

令我震惊的是，在过去的几个月里，我慢慢了解到 VS 和 MSBuild 彼此不一致。没有 VS 指导的 MSBuild 不会遵守构建顺序，因此通常会构建项目并尝试在构建依赖项之前链接它的依赖项。当项目尝试访问相同的资源而不仅仅是阻塞时，它也会失败。这些问题让我不得不在 CCNet 脚本中按项目分解我们的构建，而不仅仅是构建解决方案文件。

所讨论问题的特殊之处在于，MSBuild 将查看项目引用并尝试使用叠加在它们之上的父项目的配置和平台来构建这些依赖项。似乎 C# 项目将 x86 作为其默认平台，而 C++ 具有 Win32。我们的软件是 C#/C++/CLI 科学怪人，项目平台不一致对我的工作造成严重破坏。出于某种奇怪的原因，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 迁移，但我们希望它能够与我们现有的代码一起使用。

【问题讨论】：

我不了解科学怪人项目，但至少在纯 C++ 的情况下，我了解到如果您转换所有现有 构建顺序依赖项 在 Visual Studio 解决方案 (*.sln) 文件中指定的项目引用 在 Visual Studio C++ 项目 (*.vcxproj) 文件中指定。该平台是一个不同的主题。在我们的 VS2019 C++ 项目 (*.vcxproj) 中，我从未见过平台值是 x86，只有在 C# 项目中 (*.csproj)。对于 C++，至少在 Visual Studio 2019 中是 Win32（32 位）或 x64（64 位）。

我认为 Visual Studio for C++ 中 Win32 和 x86 之间的差异在 here 中进行了解释。这是项目或解决方案的问题。如果您在.vcxproj文件中进行修改，我认为您需要使用Win32。

【参考方案1】：

如果您将 .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

【讨论】：

这是正确答案。就 C++ msbuild 代码而言，根本没有“x86”。

知道了。是的，我知道这至少在外部是如此，并且试图调查对构建过程撒谎。我正在换档尝试以完全不同的方式解决一系列问题。在阅读了很多关于这些问题的论坛和博客之后，我必须得出结论，我们的软件已经严重过时，而且微软的构建环境完全被破坏了。