Visual Studio 和 MS 构建有不同的构建结果

Question

最近我们（与我一起工作的团队和我自己）发现 MS-build 和 Visual Studio (2015) 的构建结果之间有些奇怪。

情况

与我一起工作的团队的任务是重构一个较旧且相当大的 c# 项目，该项目包含许多 (150 多个) 项目，所有项目都捆绑到一个 sln 文件中。正如预期的那样，在我们工作期间，sln 文件中会发生合并冲突，并且其中一名团队成员错误地解决了此冲突。使 sln 文件缺少项目参考。

从这里开始，项目的行为在 3 个位置有所不同。它们如下所述

---

最初犯错的开发者的 Visual Studio

（请注意，我假设该开发人员没有清理过他的解决方案） 该程序员已经构建并运行了该项目（使用 Visual Studio 2015 Professional）。所以所有编译的 dll 文件都在 prorammers 输出文件夹中。这意味着 Visual Studio 不会注意到缺少引用。程序员可以毫无问题地构建、运行和测试应用程序。

---

构建服务器

构建服务器 (Jenkins) 不运行 Visual Studio，但它使用 MS-build 14 编译源代码。 Jenkins 服务器配置为使用管道运行，如 groovy 中所述。我们通过调用一个通过命令行运行 MS-build 的 bat 脚本来调用 ms build。一个例子：

"C:\Program Files (x86)\MSBuild\14.0\Bin\amd64\msbuild.exe" "TheSolutionFile.sln" /property:Configuration="Debug" /property:Platform="Any CPU"

即使使用不正确的 sln 文件，构建也会以某种方式成功。我怀疑 ms build 解决了它自己的依赖关系，因为 buildserver 上的工作区是干净的（完全空的），所以没有剩余的 dll 可以欺骗系统。 （我的假设是否正确？）

---

其他团队成员

其他团队成员最终会拉取损坏的 sln 文件的更改，他们会参与其中一些“乐趣”。当您的输出文件夹中没有 dll 文件时，Visual Studio 将尝试重建缺少的依赖项。但由于无法解析引用，它将失败并开始堆积有关丢失元数据的错误。在团队中，我们都使用 Visual Studio 2015。但我们也尝试使用 2017 并遇到相同的结果。最初犯错的人也可能落入这组他清理解决方案中。

问题

显然我们对构建服务器接受带有损坏的 sln 文件的构建这一事实不满意（开发人员获取最新版本无法编译或运行程序）。 有没有办法让最后两种情况同步（所以 ms build 不接受“损坏”的 sln 文件进行编译）

Answer 1

有没有办法让最后两种情况同步（所以 ms build 不接受“损坏”的 sln 文件进行编译

这是因为命令行中的 MSBuild.exe 不具有与 Visual Studio 相同的构建环境。您可以从 VS command promt 调用 MSBuild.exe，它与 Visual Studio 具有相同的构建环境。

如果您想通过调用在命令行上运行 MS-build 的 bat 脚本来调用 ms build，您可以使用 devenv.exe 从命令行构建解决方案/项目：

C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE>devenv "D:\TestSample\TestProject\TestProject\TestProject.sln" /build Debug /project "TestProject\TestProject.csproj" /projectconfig Debug

devenv.exe的详细信息可以参考Devenv Command Line。

希望对你有帮助。

Answer 2

我的建议：

.sln 文件只是项目文件的集合。创建一个全新的，并将您的 proj 文件一个一个添加。忘记代码合并冲突解决的戏剧吧。

.sln 文件中的 voodoo 太多了。让 VS 为你做这件事……当你一个一个地添加每个项目时。

文件 / 新建 / 项目 ::: 已安装 / 模板 / 其他项目类型 / Visual Studio 解决方案 ::: 空白 解决方案。

另一个提示。如果您仍然有问题，请打开每个项目和任何“by project”引用，删除它们并重新添加它们。有时 GUID 会混淆，尤其是在较长的代码合并历史中。