使用Msbuild简化.NET项目

时间:2009-09-25 15:25:53

标签: .net msbuild build-process

对不起有些模糊,但我现在领导的项目也是如此。我继承了大量各种内部工具,并试图在每个工具周围建立统一的构建系统。我们拥有的一些项目(几十个)是基于.NET的Web项目C#,其中一些是web-服务和一些webapps。这些应用程序是在过去6年中构建的,因此.NET版本从2到3.5不等。最糟糕的部分 - 所有应用程序都是使用VS构建的,没有一个是命令行构建。

要求是:我应该能够从SVN中检出代码并完全从命令行完全构建任何或所有项目而没有输入提示,因此最终可以将其集成到TeamCity中(连续整合工具)

我有C / C ++,Java背景所以我做了一些研究,一切似乎都指向MSBuild作为工具。现在过去两周我从.NET开发人员那里听到:“这很难,不可能,我们不知道该怎么做”所以现在问题就出现了:

  1. 是否可以使用仅命令行构建来改造任何现有的.Net项目?如果有限制会是什么?
  2. 我是否需要一个完整版本的VS来执行构建和部署,或者是否有一些较小的替代方案(同样,最终项目将建立在没有GUI的持续集成盒上)
  3. 我可以查看代码(从SVN)到任何目录吗?目前我被告知我需要将代码放入配置为由VS
  4. “监控”的“特殊位置”
  5. 如何管理外部依赖项?目前我从团队那里听说任何第三方库需要在使用UI构建之前“预先安装”,团队提供的最佳解决方案是“安装并创建VM”
  6. 非常感谢您的建议

1 个答案:

答案 0 :(得分:3)

这取决于你的依赖关系到底是什么,但是:

  • MSBuild是Visual Studio 2005及更高版本用作“原生”文件格式的版本 - 因此您可以非常轻松地构建VS解决方案 VS项目
  • MSBuild是.NET框架的一部分,以及各种编译器。您不需要安装VS。
  • 是的,你可以在任何地方查看SVN的代码。它不像VSS / VSTS,服务器“知道”代码在哪里
  • 外部依赖应该 - 尽可能 - 是刚存储在源代码控制中并通过相对路径引用的DLL。如果您有 要在GAC中安装的内容,那就稍微难了。

就我个人而言,我已成功使用NAnt作为构建“控制器”,但随后炮轰到MSBuild来执行实际的编译位。对于控制器位来说它比MSBuild更好(IMO),但是在实际编译方面并不像它没有跟上Visual Studio一样好。

您可以在我的Protocol Buffers port中查看其工作原理示例。