Visual Studio (.sln) 构建运行程序和 MSBuild 之间的差异
我正在尝试设置 TeamCity 使用 .Net 执行 CI 并配置构建运行程序：
- Visual Studio (sln)
- MSBuild
- Visual Studio 2003
有什么区别？为什么要在同一类型的项目上进行三个构建？ （除了 2003 年，我相信这只是 2003 年，为什么？）
考虑到这个问题，我们有这个 .exe 文件的构建运行程序：
- .NET Process Runner
- Command Line
“命令行”构建运行程序不适用于任何 .net集会？为什么选择 .Net Process Runner？
I'm trying to set TeamCity to do a CI using .Net and configuring build runners I have:
- Visual Studio (sln)
- MSBuild
- Visual Studio 2003
What's the difference? Why three build to work on the same type of project? (With the exception of 2003 which is only for 2003 I believe, Why?)
Taking the issue, we have this build runners for .exe files:
- .NET Process Runner
- Command Line
The "Command Line" build runner not works with any .net assembly? Why the .Net Process Runner?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
Visual Studio (sln)
如果您的解决方案很小并且不需要做花哨的事情，您可以使用Visual Studio (sln)构建运行器。它与执行 Project->Build（从 VS 菜单）时执行的操作完全相同。此选项非常容易配置，只需单击几下，您的 CI 服务器就会编译您的解决方案。
MSBuild
如果您需要做更多高级场景，除了简单的编译之外，例如应用不同的配置文件、将转换后的值插入配置文件、部署二进制文件等，您可以选择 MSBuild 选项。你会知道什么时候需要使用它，因为 sln builder 无法做一些事情。此选项需要一些构建脚本语言的知识，这是一种基于任务的、类似 xml 的语言。
Visual Studio (sln)
If your solution is small and you are not required to do fancy things you can use Visual Studio (sln) build runner. It does exactly the same thing as when you do Project->Build (from VS menu). This option is very easy to configure, a few clicks and your CI server compiles your solution.
MSBuild
If you need to do more advanced scenarios, apart from simple compilation, like apply different config files, insert transformed values into config file, deploy binaries etc, you would select MSBuild option. You will know when you need to use this, simply because sln builder will not be capable of doing stuff. This option requires some knowledge of build scripting language, which is a task-based and xml-like.
当您使用 MSBuild 生成 .SLN 文件（非 MSBuild 文档）时，它会生成一个内存中的 MSBuild 文件，该文件引用要在指定配置中生成的所有项目，然后执行它。当您使用 Visual Studio 构建时，您将调用 DevEnv.com。
有些项目类型（2005/2008 中的 C++ 和 2005/2008/2010 中的 VDPROJ）不是 MSBuild 文件，不能仅使用 MSBuild 进行生成。您将收到一条生成警告，指出一个或多个项目不是有效的 MSBuild 项目，无法生成。
一般来说，我会尝试维护精益且平均的构建机器，并且仅在需要时安装 Visual Studio。
When you use MSBuild to build a .SLN file ( non MSBuild document ) it generates an in memory MSBuild file that references all of the projects to build in the specified configuration and then executes it. When you use Visual Studio to build you are calling DevEnv.com instead.
There are certain project types ( C++ in 2005/2008 and VDPROJ in 2005/2008/2010 ) that aren't MSBuild files and can't be build using just MSBuild. You will get a build warning saying that one or more projects were not valid MSBuild projects and could not be built.
In geneneral I try to maintain lean and mean build machines and only install Visual Studio if needed.
我注意到两者之间很少。具体来说，在我们的实例中，我们需要构建一个 .vdproj。现在，在谷歌搜索后，有两个运行程序可以执行此操作，即命令行运行程序或 Visual Studio (sln)。但是，在执行 Visual Studio (sln) 运行程序类型时，我们收到以下错误：
“[警告] C:\BuildAgent\work\1bd75058d7bca32b\POS\PoSWidgetInstaller\myInstaller.vdproj.metaproj 警告 MSB4078：MSBuild 不支持项目文件“myInstaller\myInstaller.vdproj”，无法生成。”
当它内置在解决方案中时，它不会失败。
我认为 Visual Studio (sln) 运行程序类型从 sln 文件中提取数据，然后将其与 MSbuild 一起使用。不确定无法确认，但这只是我的想法。
I've noticed very little between the two. Specifically in our instance we needed to build a .vdproj. Now after googling there where two runners to do this, Command line runner or the Visual Studio (sln). However when doing the Visual Studio (sln) runner type we got the following error:
"[Warning] C:\BuildAgent\work\1bd75058d7bca32b\POS\PoSWidgetInstaller\myInstaller.vdproj.metaproj warning MSB4078: The project file "myInstaller\myInstaller.vdproj" is not supported by MSBuild and cannot be built."
And it doesn't fail when built in the solution.
I think Visual Studio (sln) runner type pulls the data from the sln file and then uses it with MSbuild. Not sure can't confirm but just my thoughts on it.
如果您使用解决方案文件 (Visual Studio) 方式，这意味着您需要为构建服务器授予 Visual Studio 副本以及随之而来的安装/维护许可。如果您使用 MSBuild，则不需要任何这些，您只需要安装 .net 框架即可。两者之间唯一真正的区别是 Visual Studio 设置了各种环境变量并利用了构建顺序等内容。虽然 MSBuild 默认情况下没有设置任何环境变量，并且不识别构建顺序，但它只识别依赖关系。不过在 Visual Studio 中这会稍微容易一些，并且您不会偶尔遇到依赖 Visual Studio 来掩盖一些草率的情况。
If you use the solution files (Visual Studio) way that means you need to license a copy of Visual Studio for your build server along with the installation/maintenance that comes along with that. If you use MSBuild you don't need any of that, all you need are the .net framework installs. The only real difference between the two is that Visual Studio has all sorts of environment variables set and utilitizes things like build order. While MSBuild does not have any environment variables set by default, and doesn't recognize build order, it only reconginizes the depencies. It will be slightly easier though in Visual Studio and you won't run into those cases occasionaly where you were depending on visual studio to cover up some sloppiness.