为什么我应该使用MSBuild而不是Visual Studio解决方案文件？

我们正在使用TeamCity进行持续集成，并通过解决方案文件（.sln）构建我们的发行版。过去，我曾在各种系统上使用过Makefile，但从未使用过msbuild（我听说这有点像Makefiles + XML mashup）。我已经看到很多关于如何直接使用msbuild而不是解决方案文件的文章，但是我对为什么要使用msbuild并没有一个很明确的答案。

那么，为什么还要麻烦从解决方案文件迁移到MSBuild“ makefile”呢？我们确实有几个版本，它们之间的区别是#define（功能完善的版本），但大多数情况下一切正常。

更大的问题是，现在添加项目/源代码时，我们必须维护两个系统。

更新：

人们能否阐明以下三个组成部分的生命周期和相互作用？

1. Visual Studio .sln文件
2. 许多项目级别的.csproj文件（据我了解，这是一个“子” msbuild脚本）
3. 自定义msbuild脚本

可以肯定地说，在自定义msbuild脚本是手写的并且通常以“原样”使用已经存在的单个.csproj的情况下，从Visual Studio IDE GUI照例使用/维护.sln和.csproj吗？这是我可以看到减少维护重叠/重复的一种方式...

希望从其他人的操作经验中得到一些启发

事实的第一点是，当MSBuild执行解决方案文件时，解决方案文件几乎神奇地变成了MSBuild文件-这是在Visual Studio中构建解决方案时发生的情况。此外，所有这些项目文件都是由Visual Studio管理的msbuild文件。实际上，无论您是从解决方案中构建还是从自定义msbuild脚本中构建，项目文件都可以处理大多数真正的脏活。

我们还使用TeamCity来构建和发布应用程序，并且通常会以大多数项目的自定义msbuild脚本结束。这些脚本所扮演的角色（对于解决方案文件而言确实并不容易）将打包项目以进行部署或分发。通常，这些脚本处理更多的操作方面的事情-例如将Web项目构建到特定的文件夹中或在运行配置中复制而不是在开发配置中复制。繁重的工作通常由项目文件本身处理-构建脚本仅引用这些文件，我们不尝试重新创建该文件。总的来说，它运行良好，并且几乎没有重复的代码。

msbuild的makefile 是 .sln文件（或vcproj文件）。

典型的msbuild命令行如下所示：

msbuild /p:Configuration=Release BigProject.sln

使用msbuild的目的是使您可以编写脚本并自动执行生成过程。无论您是否意识到，TeamCity一直都在使用msbuild。

让我对这个问题发表看法。

尽管您当然可以简单地将.SLN文件用作“构建过程”，但该文件本身实际上并不构成构建过程。解决方案文件实际上只是Visual Studio的一部分，用于开发。但是Visual Studio只是构建和发布过程的一部分。您不能依靠解决方案来管理构建，并且解决方案当然不能提供可扩展的构建情况。

建立构建过程的全部目的是创建可靠的构建。也就是说，构建过程非常可靠，因此无论构建配置如何，您都将获得可预测的构建输出。每次，每台机器。可预测和可靠构建的结果是测试，部署和发布过程可以高度自动化，从而进一步降低了人为错误的风险。

建立构建过程需要投资，但是在某些情况下，需要投资。以下是一些有利于msbuild进程的因素：

• 您的产品有多个团队（跨职能团队或其他团队）在同一团队项目中工作
• 您的组织只有一个团队项目（99％的传统商店应该是这样，即使那些拥有200多个开发人员的商店也是如此）
• 您需要构建20多个项目，其中一些项目依赖于其他项目并由不同的团队维护
• 您的产品包含多种.NET技术（C＃，C ++，VB，F＃，ASP.NET等），甚至还包含非.NET技术（Grunt，node，npm，Java等）
• 您的产品具有重量级依赖项，或在重量级平台上构建。以SharePoint为例

让我举一个例子来扩展我的最后一点。我目前的公司从事SharePoint开发。SharePoint开发至少需要安装SharePoint基础才能在SharePoint项目上执行构建。说到轻量级构建服务器，要求构建服务器安装SharePoint是完全不切实际的。SharePoint不仅是具有很高要求的野兽，而且还会对构建产生严重的性能影响-并且构建应尽可能快且精简。利用MSBuild，我可以消除在生成服务器上的安装要求。实际上，除了.NET框架（MSBuild要求）和Node外，我们的构建服务器没有安装要求。

作为参考，我建议您查阅Sayed Ibrahim Hashimi的这本书：http ://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248/ref=sr_1_fkmr0_1?ie = UTF8&qid = 1412014650&sr = 8-1-fkmr0＆keywords = msbuild + reliable + build

这正是我几个月前问自己的问题！我们对所有设置进行了很好的设置：

• 解决方案文件很好地位于存储库的根目录中
• 在Teamcity中配置的构建步骤，例如
  • 恢复NuGet软件包
  • 建立解决方案
  • 运行单元测试
  • 设置集成测试环境
  • 运行集成测试
  • 拆解集成测试环境
  • 创建部署程序包
  • 构建迁移脚本

然后，在可重复性方面，很明显它的得分很低。当您将TeamCity用作构建脚本时，很难在您自己的开发计算机上重现可靠的类似结果。

当您拥有一个构建脚本时，该构建脚本就知道了所有需要完成的工作，并且所有变量都就位。当您使用CI服务器作为构建脚本时，会发生一些问题，例如复杂的测试失败或需要手动构建部署程序包（按照我的示例），您需要手动将构建的所有步骤拼凑在一起。

因此，在短，为什么（MS）构建脚本？因为您最终会对构建产生更多要求。您可能想要运行一些测试并从中生成一些工件。您可能想要进行部署。而且，当您想要的所有内容都需要可运行时，无论是在构建服务器上还是在您的计算机上，它都只能在构建脚本中结束。