用于Visual Studio项目的独立构建系统

Question

我们使用Make来编译我们的产品，其中包括C，C++，Java和其他一些零散件。尽可能多地将所有检查到的东西编译为源代码管理，消除本地依赖并确保各个开发机器之间的一致性。

最近我们添加了一些用C＃编写的使用Visual Studio的组件，并希望对Visual Studio解决方案采取类似的方法。去掉devenv不是一个好的选择。直接调用csc.exe（正如我之前使用Nant所做的那样）需要跟踪构建脚本中的文件依赖关系，我宁愿让Visual Studio解决方案执行此操作。

MSBuild似乎是一个不错的选择，虽然它在%windir%\Microsoft.NET\Framework\[version]\的默认位置让我担心机器之间的差异，包括路径中的[版本]以及您将同时看到“Framework”和“Framework64”目录。我不介意要求所有开发人员安装任何.NET Framework版本，但我担心您的v3.5可能与我的版本不一样。

有没有人有解决方案，他们喜欢这个？试过了你真的不喜欢的东西？

Answer 1

当然MSBuild是最低摩擦的选项。不同的fx版本在构建时并不是什么大问题 - 如果你使用的fx版本比安装的版本重要，那么它将无法构建。在我最后一个地方，我们构建了一个以NAnt为基础的巨大的多环境构建系统，并且使用NAnt的MSBuild任务吸引了MSBuild。如果你只是在做微软的东西，MSBuild很好，但是我们有一些MSBuild本来不支持的东西，因此NAnt包装器。

Answer 2

MSBuild是此工作的最佳工具。只需将您的框架版本与您使用的Visual Studio捆绑在一起的框架版本匹配即可。

32位与64位无关紧要，我不认为 - 我敢肯定，Csc.exe的32位和64位版本都可以交叉编译到其他平台。 MSBuild项目文件（*。* proj XML文件）应包含MSBuild构建应用程序所需的所有内容。

Answer 3

我同意其他人的意见。为了简单起见，只需将vsvars.bat（Visual Studio命令提示符的批处理文件）作为构建脚本的一部分，然后MSBuild将正常工作。

Answer 4

我们使用Nant来驱动msbuild。如果您担心该框架的不同版本，特别是Service Pack，请使用FxCop检查是否不让意外的依赖项出现。详细信息请见this answer。