如何在Visual Studio中实现自动化构建?

9
我在一家小的 .net 店里工作,我们目前使用 visual studio IDE 构建所有解决方案。我们希望能够完全控制我们的 MSBuild 脚本以进行构建、测试和部署,利用 MSBuild 社区任务等。
我的问题是:在 Visual Studio 开发体验中有什么不同?
如果我们创建自己的 MSBuild .proj 文件,那么这是否意味着我们不再拥有 .csproj 文件?现在 VS 中的项目是什么样子?
我是否漏掉了一些非常明显的东西?
更新: 感谢大家抽出时间来回复。 我知道一些构建工具,如 CruiseControl、TeamCity 等,也知道 vs 项目(.csproj 等)只是 MSBuild 文件。 我试图了解的是那些决定编写自己的脚本和 .proj 文件的人。他们是否像使用 VS .csproj 文件一样,只是在 IDE 中保存代码文件的“容器”?他们如何触发自己的开发构建?他们只是从命令行启动 MSBuild 吗?还是在工具栏上有一个按钮可以实现相同的功能?
总之,您确实可以使用其他工具通过调用 .sln 文件或 .csproj 文件来推动构建,但还有另一种方法-它是如何工作的?

1
顺便说一句,为转向自动化构建流程点赞!一旦你让它运行起来,你会想知道为什么一开始还要手动操作。 - John Feminella
我们的目标之一是实现“单击”发布流程(尽管不要立即发布)。现在我只是在努力想出如何变成“双击” :),因为很容易意外触发发布构建,在源代码控制中创建标签等,然后必须去清理。 - Chris Chilvers
兄弟,那正是我想要到达的地方。你如何触发这些构建? - Pete Morgan
使用 Hudson 和其中的特定任务,以及自定义的 .proj 文件来处理构建过程中的压缩、复制、标记等特定操作。 - Chris Chilvers
6个回答

6
我们使用msbuild进行自动化构建,您只需将msbuild指向您的解决方案文件即可,无需进行任何更改。
此外,我们还使用一个自动化构建服务器(带有.Net插件的Hudson),该服务器使用msbuild来自动化处理过程。

1
恭喜您转向自动化构建流程 :-) - jamesaharvey
这正是我们所做的。通过Hudson进行MSBuild构建,效果非常好。 - Soo Wei Tan
你正在使用Hudson运行你的解决方案文件?如果你想要执行额外的任务(如压缩/创建IIS虚拟目录等),你该如何将其纳入你的构建脚本中呢? - Pete Morgan
在Hudson中,您还可以添加其他命令行脚本,在msbuild步骤完成后执行其他任务。 - jamesaharvey
我认为使用更多的msbuild或nant脚本比使用命令行更好,虽然powershell也可以接受。批处理文件太过受限制了。 - Chris Chilvers
显示剩余2条评论

2
你应该看看CruiseControl.NET,而不是自己开发自动化构建和CI流程。它可以让你的生活更轻松,并且可以在构建过程中运行测试或代码覆盖率工具等其他功能。请查阅CruiseControl.NET了解更多信息。

我一直以为CruiseControl是在构建服务器上定期/每日/每周/连续运行的东西。你不会将其用于日常开发人员特定的编译/测试构建,对吧? - Pete Morgan
@Pete:是的,你说得对。构建的触发器当然是可调的(通常在提交时),但它不是开发人员桌面工具(据我所知)。 - JP Alioto

2
Visual Studio的开发体验会有什么不同吗?
通常来说,没有什么不同。实际上,如果你做得对,这应该是透明的;你的IDE不应该关心你使用了哪个构建管理器。这就是为什么像CruiseControl.NET和Hudson这样的解决方案很好的原因。
如果我们正在创建自己的MSBuild .proj文件,那么这是否意味着我们不再拥有.csproj文件?现在项目在VS中是什么样子的?
你的解决方案结构保持不变。在Visual Studio中,解决方案和项目既充当项目组织/打包指南,又作为IDE的便利工具。你的构建管理器将检查这一点,以了解需要构建什么。

谢谢约翰。我得去了解一下Hudson。 - Pete Morgan

2

有几个很好的自动化和连续构建工具可用,这些工具基于MSBuild。您的C#项目文件已经是MSBuild文件 - 因此实际上,自VS2005以来,您已经在本地工作站上使用MSBuild来创建构建 - 您可能只是不知道 :-)

除了JP提到的CruiseControl.NET(绝对值得一看),我还推荐两个产品:

  • FinalBuilder Server,似乎几乎没有被大多数开发人员知道(但它绝对值得更多的关注!非常优秀的工具)。他们还有一个独立的桌面版 FinalBuilder 如果您可能需要的话。它不是免费的,但对于一个用户100美元(5个用户450美元),真的不是很大的支出。

  • TeamCity 由JetBrains开发 - 在.NET世界中以其Resharper产品而闻名 - 为团队提供免费的Pro版本,适用于最多20个用户/构建计划,并提供一个更昂贵的企业版,如果您已经发展壮大 :-)

与CruiseControl.NET相比,两者都提供了友好的GUI界面来配置和监控构建过程。 正如我之前提到的-两者都建立在您现有的项目和解决方案文件结构之上,因此完全无需更改任何内容。 持续集成真的是一个不错的选择!我再也不能没有即时的构建反馈了...... 马克

企业版并不贵,如果你已经发展到可以使用它的程度。 - Chris Chilvers
谢谢Marc。我想问你和我上面问James的同样的问题:如果你想要执行其他任务(例如zip /创建IIS虚拟目录等等),你会如何将它们纳入您的构建脚本? - Pete Morgan
FinalBuilder和TeamCity都提供了这些额外的任务。您的解决方案文件描述了如何构建解决方案及其项目 - 其他步骤在CI脚本中。您可以压缩输出,将其复制到共享或FTP服务器,启动虚拟机并运行安装以及几乎任何您能想到的其他操作!这些命令在Finalbuilder或TeamCity脚本中 - 在您的解决方案/项目文件中。 - marc_s
我已经在上面添加了这个,但有时候注释会被忽略,所以你可以直接在.csproj文件中尝试预构建和后构建事件,它们可能有效。 - GR7
是的,但这些功能相当有限 - 大多数CI工具都拥有丰富的功能集,通常比您可以在批处理文件中直接在VS中进行的构建前或构建后更好。 - marc_s

1

我们在工作中使用TeamCity;我们最初使用CruiseControl.NET,但当另一个开发人员指出我否则将永远维护cc构建时,我们进行了切换。;) 说真的,TeamCity非常容易学习和使用。

当我第一次听到持续集成时,我问了类似的问题。您是否必须手动重写(并维护)所有解决方案和项目?您需要学习MSBuild命令吗?简短的答案是否定的。

正如Harvey先生所提到的,您可以简单地调用VS创建的解决方案或项目文件上的MSBuild,它会为您构建。TeamCity将自动处理此过程。

如果您想要更多的灵活性,我建议使用NAnt。我曾经使用手工编码的MSBuild脚本,这是一种令人沮丧的练习。NAnt具有更清晰的语法,并且(对我来说)更易于使用和阅读。我们在高级功能中使用NAnt,并且(再次)在我们想要构建项目或解决方案时从NAnt调用MSBuild。TeamCity支持NAnt。

总结一下,在 Visual Studio 中对我们来说没有什么真正的变化。我们仍然以同样的方式创建和维护项目和解决方案。当我们将它们检入源代码控制(TFS)时,TeamCity 会自动捕捉到这些更改,构建解决方案并运行我们的(NUnit)测试。我们还设置了一键部署构建(在 TeamCity 中使用 NAnt)。

酷!谢谢你,威尔。 我一直在考虑是走Nant还是MSBuild路线。我知道有很多像你这样的人认为Nant在处理高级操作时更加“舒适”,但是我不知道自己是否能够掌握到那个水平。 此外,也许一年后我会用Rake或者其他方式在IronRuBy上完成所有这些事情!;-) - Pete Morgan
实际上,使用现代CI构建软件,你通常根本不需要编写花哨的构建脚本。它们只是你工具箱中的另一个工具。 - TrueWill

1
感谢大家的回复,但是通过一些研究,我发现了一些不同的方法:
  • 扩展构建过程,超越 .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并查看结果! :-)

顺便问一下,如果还有人在这个时候阅读并对我在自己的答案中呈现的东西有意见,无论是好是坏,正确或错误,过度或过时,有缺陷或其他,请随时发表您的意见。

好的, 皮特。


顺便说一句 - 我意识到我实际上并不需要做这些事情 - 我可以简单地按照詹姆斯和其他人建议的去做。我只是想亲自找出我最舒适的方式。 - Pete Morgan

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接