最近我们（我和我一起工作的团队）在MS-build和Visual Studio（2015）的构建结果之间看到了一些奇怪的东西。
我与之合作的团队的任务是重构一个较旧且相当大的c＃项目，该项目包含许多（150多个）项目，这些项目都捆绑在一个sln文件中。至于预期合并冲突发生在我们工作期间的sln文件中，并且其中一个团队成员错误地解决了这种冲突。保留sln文件缺少项目参考。
从现在开始，项目的行为在3个位置是不同的。它们如下所述
（请注意，我假设此开发人员不清理了他的解决方案） 该程序员已经构建并运行该项目（使用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构建时不接受破解的＆＃39; sln文件进行编译）
答案 0 :(得分：1)
有没有办法让最后两种情况同步（所以ms build不接受'破坏'的sln文件来编译
这是因为命令行中的MSBuild.exe 与Visual Studio具有相同的构建环境。您可以从VS command promt调用MSBuild.exe，它具有与Visual Studio相同的biuld环境。
如果您想通过调用在命令行上运行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。
希望这可以帮到你。
答案 1 :(得分：0)
我的建议：
.sln文件只是项目文件的集合。创建一个全新的，并逐个添加您的proj文件。忘掉代码合并冲突解决方案的戏剧。
.sln文件中的voodoo太多了伏都教。让VS为你做...当你逐个添加每个项目时。
文件/新建/项目:::已安装/模板/其他项目类型/ Visual Studio解决方案:::空白 溶液
另外一个暗示。如果您仍有问题，请打开每个项目，以及任何项目＆＃34; 引用，删除它们并重新添加它们。有时GUID会混淆，特别是在长代码合并历史记录中。