我想知道人们是否认为值得学习MSBuild语法来定制 .net 项目的构建过程，或者说考虑到使用 Visual Studio 构建项目的简单性，这样做真的不值得吗？
我的考虑是夜间构建等方面的问题，但是我可以使用内置在 VS 中的命令行构建选项来进行计划事件吗？还有更好的工具吗？
10个回答
15
我认为是的。
MSBuild 的好处在于，如果您修改 csproj 文件以包含自定义构建步骤，则这些步骤将在 VS 或 MSBuild 中发生。此外，如果您有一个构建服务器，您将不需要安装完整的 VS，只需要 SDK 来构建您的项目。
MSBuild 的好处在于，如果您修改 csproj 文件以包含自定义构建步骤，则这些步骤将在 VS 或 MSBuild 中发生。此外，如果您有一个构建服务器，您将不需要安装完整的 VS，只需要 SDK 来构建您的项目。
- Andrew Burns
13
MSBuild绝对值得学习。在初始的学习曲线（实际上可能非常陡峭）之后，进行最常见的构建自动化步骤变得相当容易。
- 以RELEASE模式构建程序集
- 使用强名称签名程序集
- 运行单元测试
- 即时修改xml文件/Web.config文件
- 修改程序集的版本号
- 验证FxCop/StyleCop等工具
- 自动化部署-创建SQL数据库，IIS网站，Windows服务等等
- Jivko Petiov
8
MSBuild是.NET软件编写人员必须学习的技能。如Andrew Burns所说，.NET应用程序的构建服务器不再需要安装Visual Studio，因为MSBuild现在已经成为.NET Framework的一部分。
了解MSBuild将使您在选择实施持续集成所使用的技术方面具有重大的灵活性。由于我花时间学习了MSBuild，因此我能够很容易地将我们团队中一个正在使用CruiseControl.NET的CI系统更改为TeamCity。这些CI服务器或类似FinalBuilder（我不熟悉）的工具是执行夜间构建的更好选择，而不是计划任务。学习如何实现自定义MSBuild任务将为您在实施自定义构建方案时提供更多的灵活性。Jivko Petiov列出了许多MSBuild使得更容易的任务。在数据库部署和配置方面，我编写了使用MSBuild的脚本，这使得开发和测试过程更加轻松。
如果您未来要使用Visual Studio Team System，那么使用MSBuild构建的应用程序将比通过其他方式构建的应用程序更容易移入该环境中。
有很多资源可帮助您开始使用MSBuild。我建议从Inside the Microsoft Build Engine开始。其中一位合著者在网上有大量资源，包括这个网站和一个CodePlex项目。
了解MSBuild将使您在选择实施持续集成所使用的技术方面具有重大的灵活性。由于我花时间学习了MSBuild，因此我能够很容易地将我们团队中一个正在使用CruiseControl.NET的CI系统更改为TeamCity。这些CI服务器或类似FinalBuilder（我不熟悉）的工具是执行夜间构建的更好选择，而不是计划任务。学习如何实现自定义MSBuild任务将为您在实施自定义构建方案时提供更多的灵活性。Jivko Petiov列出了许多MSBuild使得更容易的任务。在数据库部署和配置方面，我编写了使用MSBuild的脚本，这使得开发和测试过程更加轻松。
如果您未来要使用Visual Studio Team System，那么使用MSBuild构建的应用程序将比通过其他方式构建的应用程序更容易移入该环境中。
有很多资源可帮助您开始使用MSBuild。我建议从Inside the Microsoft Build Engine开始。其中一位合著者在网上有大量资源，包括这个网站和一个CodePlex项目。
- Scott Lawrence
7
看起来你是一位单独开发自己的网站的开发者。如果这是情况，那么这并不是必须的，但作为专业经验的一部分学习这个仍然是一个好主意。
随着参与项目的开发人员数量的增加，自动化项目构建变得更加必要。两个开发人员很容易写出不兼容的代码，在组合时导致代码崩溃（想象我调用了函数 foo(int x)，而你将其参数改成了 foo(int x, int y)：当我们组合我们的代码库时，代码将会崩溃）。
这些类型的错误会随着集成构建之间的时间增加而变得越来越复杂和麻烦。通过设置每夜构建，甚至在每次提交时进行构建，可以大大减少这些问题。这种做法已经成为拥有多个开发人员的项目中的行业标准。
现在，回答你的问题：这是一项跨项目和公司的技能。你应该学习它来扩展你的知识和技能作为一个开发人员，并在你的简历上添加一个重要的内容。
随着参与项目的开发人员数量的增加，自动化项目构建变得更加必要。两个开发人员很容易写出不兼容的代码，在组合时导致代码崩溃（想象我调用了函数 foo(int x)，而你将其参数改成了 foo(int x, int y)：当我们组合我们的代码库时，代码将会崩溃）。
这些类型的错误会随着集成构建之间的时间增加而变得越来越复杂和麻烦。通过设置每夜构建，甚至在每次提交时进行构建，可以大大减少这些问题。这种做法已经成为拥有多个开发人员的项目中的行业标准。
现在，回答你的问题：这是一项跨项目和公司的技能。你应该学习它来扩展你的知识和技能作为一个开发人员，并在你的简历上添加一个重要的内容。
- Trav
5
- michaelpryor
2
在您目前没有构建系统的情况下，MSBuild是非常值得使用的，尤其是与持续集成环境（如CruiseControl）相结合。不仅可以用于各种预构建和后构建任务（参见Jicko Petiov的答案），而且还可以很好地集成到持续集成环境中。
但如果您已经有了自动化/脚本化的构建系统，则可能不值得使用MSBuild。例如，我自己之所以没有花时间学习MSBuild，是因为在MSBuild出现之前我一直在使用NAnt来完成这个任务...
但如果您已经有了自动化/脚本化的构建系统，则可能不值得使用MSBuild。例如，我自己之所以没有花时间学习MSBuild，是因为在MSBuild出现之前我一直在使用NAnt来完成这个任务...
- John Rudy
2
MSBuild非常容易使用，您可以使用VS来管理项目和解决方案文件，只需将SLN传递给MSBuild即可。
- Jonathan Holland
1
如果你在开发方面使用.NET工作室，学习是值得的。
我已经将我们的构建过程与Jenkins集成 - 最初是Hudson。
正如上面提到的，MSbuild具有陡峭的学习曲线。然而，一旦掌握了基本原理，就可以开始定制构建。
到目前为止，我的印象可能很幼稚，脚本的大部分由...组成。
<PropertyGroup>
<PropertyKey>value</PropertyKey>
</PropertyGroup>
<ItemGroup>
<ItemListKey>List values<ItemListKey>
</ItemGroup>
<Task Source="" Target="" />
除了用于构建之外，我还成功地使用MSBuild创建了一个模块，用于管理配置文件，如web.config和foo.exe.config文件。 它是一个混合模块，由.NET控制台应用程序、MSBuild脚本和批处理文件组成。 这个模块的作用是，在项目升级期间，从旧的配置文件中创建一个包含连接字符串、端点和appSettings的XML转换模板。 在项目升级完成后，该模块将转换新部署的配置文件，而不会影响任何新条目。如果你有几十个配置文件，这非常有效。
- yantaq
1
使用MSBuild命令行进行构建相对而言较容易学习。首先打开Visual Studio命令提示符，然后运行msbuild /?。只需要阅读帮助一次，然后稍后再决定是否要了解更多细节。
编写项目文件则稍微复杂一些。大多数人不需要学习它，因为你可以在Visual Studio中完成大多数操作。但是，对于某些问题，它也非常强大。
我过去曾将MSBuild用作脚本语言，结合大量自定义任务使用。MSBuild具有出色的日志记录支持和内置的依赖项管理。但是，它不是一个易于学习的语言。PowerShell是一个更好的选择。
- Jay Bazuzi
0
@kronoz 我想说是的。MSBuild的好处在于，如果你修改了csproj文件以包含自定义构建步骤，那么这些步骤将在VS内部或从MSBuild中执行。此外，如果您有一个构建服务器，则不需要安装完整的VS，只需要SDK即可构建您的项目。
==> 这并非完全正确。例如，在构建服务器上构建安装程序项目将需要安装Visual Studio！！
==> 这并非完全正确。例如，在构建服务器上构建安装程序项目将需要安装Visual Studio！！
- JoDG
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接