感谢大家的回复,但是通过一些研究,我发现了一些不同的方法:
- 扩展构建过程,超越 .sln 和 .csproj 文件的限制
- 仍然使用 Visual Studio
- 尽可能地保持在 MSBuild 的世界中
- 根据需要添加构建服务器(如 TeamCity 和 Hudson)的功能
- 但不依赖于这些服务器提供构建脚本应该提供的功能。
所以我找到了:
Scott Hanselman 的这篇旧博客文章code organisation。在这里,他使用 Nant 而不是 MSBuild,但基本概念是通过 .bat 批处理文件执行任何你想要的 nant/msbuild 项目。
"在这个源目录中,我们有像 build.bat 和 buildpatch.bat 这样的东西。目标是让人们可以从源代码控制获取东西并输入 BUILD,然后就能得到有用的东西。能够可靠而简单地构建整个系统非常令人放心。"
从这可以看出,他(显然)仍在使用.sln和.csproj将文件组合在一起以供VS使用 - 如果需要,可以通过VS进行构建 - 但实际上通过Nant .build文件执行构建,再通过.bat执行。
这篇其他的帖子(同样来自Scott Hanselman)展示了如何在Visual Studio中执行外部工具(例如MSBuild或.bat文件)。所以我创建了一个看起来像这样的build.bat文件:
@echo off
echo Building %1 solution from build.bat
echo Directory: %~p1
C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe %~f1 %2
我从这里得到了有趣的~p和~f参数修饰符;%~f1将MySolution.sln扩展为完全限定路径的sln) ;-)
然后,我设置了Visual Studio“外部工具”对话框,使其:
- 命令是“build.bat”
- 参数是“$(SolutionFileName) /v:m”
- 初始目录是“&(SolutionDir)”
然后,我在工具栏上添加了一个按钮来执行它。
我可以进一步将F5键映射到运行此操作,而不是标准的Visual Studio构建。
无论如何,这些只是一些想法(诚然是来自别人的大脑!),但它让我更深入地了解了构建以及如何完成它们。存在一些限制(例如错误不会出现在错误列表窗口中),但如果需要,我相信这些限制可以克服。
我将尝试使用MSBuild单独完成此操作,然后还要尝试连接到Hudson并查看结果! :-)
顺便问一下,如果还有人在这个时候阅读并对我在自己的答案中呈现的东西有意见,无论是好是坏,正确或错误,过度或过时,有缺陷或其他,请随时发表您的意见。
好的,
皮特。