【发布时间】: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。
标签: c# c++ visual-studio msbuild visual-studio-2017