Visual Studio(.sln)构建运行器和MSBuild的区别。

Question

我正在尝试使用 .Net 配置构建运行器在 TeamCity 上进行 CI，以下是我拥有的构建运行器:

1. Visual Studio (sln)
2. MSBuild
3. Visual Studio 2003

它们之间有什么区别？为什么针对同一类型的项目需要三种构建工具？（除了2003只适用于2003，为什么？）

就这个问题而言，我们有以下两种构建运行器可用于 .exe 文件：

1. .NET 进程运行器
2. 命令行

"命令行" 构建运行器不能与任何 .net 程序集一起使用吗？为什么要使用 .Net 进程运行器？

- Acaz Souza

Answer 1

Visual Studio (sln)
如果你的解决方案比较小，而且不需要进行高级操作，那么你可以使用Visual Studio (sln)构建运行器。这个工具和从VS菜单中进行Project->Build操作得到的结果一模一样。这个选项很容易配置，只需点击几下，就可以让CI服务器编译你的解决方案。

MSBuild
如果你需要完成更多高级场景，除了简单的编译之外，例如应用不同的配置文件、将转换后的值插入到配置文件中、部署二进制文件等等，那么你需要选择MSBuild选项。当你发现sln构建器无法胜任工作时，你就会知道需要使用它。这个选项需要一些构建脚本语言的知识，它是基于任务和xml的。

- oleksii

---

谢谢回答。Visual Studio（sln）在幕后使用MSBuild，对吧？ - Acaz Souza

Visual Studio可以构建一些MSBuild无法构建的项目类型（例如安装程序项目）。至少这是我在使用VS 2008时的经验 - 也许现在更加同步了。 - Joey

@Acaz 嗯，是的，但所有的都对你隐藏了起来。当你在 VS 中进行构建时（Project->Build），实际上使用的是 MSBuild，但你根本不知道这一点。这里也是同样的过程，为了简单起见，您可以配置您的 CI 直接编译项目。 - oleksii

还有一些工具，比如OpenMake Build Meister，它可以更好地分析项目之间的关系和需要重新构建的过时目标，然后生成自己的MSBuild文件，以便在多个解决方案之间实现更好的线程处理。例如，我曾经参与开发一个系统，其中有数十个解决方案和数千个项目，我们能够大幅减少构建时间。 - Christopher Painter

MSBuild 是一种面向任务的构建工具。它可以编译、运行单元测试、部署二进制文件、归档，执行配置文件转换等等。在这些过程中，它使用其他工具或库。例如，为了编译 C# 解决方案，它会使用 scs.exe；为了运行 NUnit 测试，它可以使用 nunit-console.exe。因此，简而言之，它是一个包装器，允许您自动化产品的构建、测试和部署流程。 - oleksii

Answer 2

当您使用MSBuild构建一个 .SLN 文件（非 MSBuild 文档），它会生成一个内存中的 MSBuild 文件，该文件引用了指定配置中要构建的所有项目，然后执行它。当您使用 Visual Studio 构建时，实际上是在调用 DevEnv.com。

有一些项目类型（C++ 在 2005/2008 年和 VDPROJ 在 2005/2008/2010 年）不是 MSBuild 文件，不能仅使用 MSBuild 进行构建。您将收到一个构建警告，说明一个或多个项目不是有效的 MSBuild 项目，无法进行构建。

通常情况下，我会尽量保持构建机器的轻量化，并只安装必要的 Visual Studio。

- Christopher Painter

---

你是指 DevEnv.exe。 - Nikhil Agrawal

请查看您的Common7\IDE文件夹，您会看到一个DevEnv.exe和一个DevEnv.com。如果您执行devenv.exe /？，您将获得一个带有命令行选项的模态窗口。如果您执行devenv.com /？，它将全部显示在stdout上。如果您执行echo %PATHEXT%，您将看到.COM列在.EXE之前。因此，在构建期间调用DevEnv时，实际上是调用DevEnv.com，以便可以收集和处理所有stderr和stdout到您的日志文件中。 - Christopher Painter

我会说，我在最后所说的“瘦而简”的评论反映了我在2005-2012年左右的观点。这是一个很好的目标，但现在不太实际了。虽然 MSFT 有构建工具，并且可以通过 Nuget 拉取很多内容，但实际情况是经常存在边缘案例，您只需安装完整的 Visual Studio 工作负载即可解决问题。我认为这有点悲哀，但它就是现实。 - Christopher Painter

Answer 3

我注意到两者之间几乎没有什么区别。具体来说，在我们的实例中，我们需要构建一个.vdproj文件。现在，在谷歌搜索后，有两个运行器可以做到这一点，命令行运行器或Visual Studio（sln）。然而，当使用Visual Studio（sln）运行器类型时，我们遇到了以下错误：

"[警告] C:\BuildAgent\work\1bd75058d7bca32b\POS\PoSWidgetInstaller\myInstaller.vdproj.metaproj warning MSB4078: 项目文件“myInstaller\myInstaller.vdproj”不受MSBuild支持，无法构建。"

但是，在解决方案中构建时并不会失败。 我认为Visual Studio（sln）运行器类型从sln文件中提取数据，然后将其与MSbuild一起使用。不能确定，但这只是我的想法。

- Nate

Answer 4

如果你使用解决方案文件（Visual Studio）的方式，那么这意味着你需要为你的构建服务器许可一个 Visual Studio 的副本以及伴随而来的安装/维护。如果你使用 MSBuild，你不需要任何额外的东西，所有你需要的只是 .net 框架的安装。两者之间唯一真正的区别在于，Visual Studio 设置了各种环境变量并利用了诸如构建顺序之类的东西。而 MSBuild 默认情况下没有设置任何环境变量，也不识别构建顺序，它只识别依赖关系。虽然在 Visual Studio 中可能稍微容易一些，而且你不会偶尔遇到那些依赖于 Visual Studio 掩盖一些不规范代码的情况。

- Alex

---

抱歉，但那不是它。我正在使用服务器上的“Visual Studio Runner”查看绿色构建，我只安装了“MSBuild工具”和“Windows SDK”，这两个免费产品可以从MS网站下载。 - MoonStom