代码之家 › 专栏 › 技术社区 › jerhinesmith

MSBuild--使用.csproj文件还是自己滚动?

mbunit cruisecontrol.net continuous-integration msbuild version-control

jerhinesmith · 技术社区 · 17 年前

好吧,所以我很乐意承认,在持续集成方面,我是个新手。

话虽如此,我正试图设置一个CC.NET环境来自学,但我很难找到设置自动构建部分所需的信息。

据我所知,在C#中,VS 2005及其后续版本生成的.csproj文件是有效的MSBuild文件。也就是说,我已经能够使用.csproj文件将MSBuild任务集成到CC.NET中,但我有一些问题:

这里有很多我不确定在自动化构建环境中是否真正需要的东西。
我没有创建这个文件。我不明白,这让我害怕( Programming By Coincidence )
大部分正在发生的事情似乎都是抽象的 $(MSBuildToolsPath)\Microsoft.CSharp.targets
作为1、2和3的结果,修改文件以包含MbUnit之类的内容似乎很复杂,而且比实际需要的要困难得多。我唯一真正的选择是将其包含在 AfterBuild 在我看来,这有点像黑客。

那么,给CC.NET人员、MSBuild人员和MbUnit人员几个问题。

使用MSBuild时,建议使用VS生成的.csproj文件作为生成文件吗?还是我应该创建自己的?
MbUnit测试应该是MSBuild文件还是CC.NET文件的一部分?我的研究似乎表明它们属于MSBuild文件。如果是这样的话,除了.csproj文件之外,我是否还要创建一个新的MSBuild.proj文件并将其签入CVS?或者MbUnit任务会成为我的.csproj文件的一部分吗?
与问题2类似。如果我将MbUnit测试添加到MSBuild文件并最终使用.csproj文件 Target Name="AfterBuild" 真的需要添加这些信息吗?难道不应该有 Target Name="Test" 部分?使用VS生成的.csproj文件似乎阻止了第二种选择。

我知道那里有很多,但我在网上找到的大部分内容都假设我对这些主题有一定程度的熟悉,而我只是没有——除非我错了,否则这些东西的学习曲线根本不是曲线,而是阶跃函数。 :)

编辑1:我更新了文本,使其更加简洁,并解决了我对答案的一些挥之不去的问题。

7 回复 | 直到 17 年前

Rob Hunter 17 年前

我建议使用生成的.csproj文件——事实上,对于生产环境,我认为使用生成的.sln文件是一个好主意。我发现,使用与开发人员相同的解决方案文件会让你受益匪浅。

请注意,.sln文件实际上不是有效的msbuild项目文件——当它们用作输入时,它们会被msbuild本身转换为msbuild项目。狡猾!

出于学习目的,您可能希望记录.csproj的构建并逐步了解正在发生的事情。MSBuild比nant更具声明性,所以请慢慢尝试。

最后,我将把你的.sln或.csproj文件包装在一个带有msbuild任务的连续构建脚本项目中,以构建你的项目并一起运行单元测试。这样,开发人员就不必每次构建时都运行单元测试,但每次集成代码时,单元测试都会运行。是的,确保他们跑得快!任何需要超过一秒钟的东西都应该在计划的(每晚?)构建期间运行。如果需要超过一秒钟的时间,它们可能是更少的单元测试,更多的是用单元测试框架编写的集成测试。

编辑: 我发现了一些有用的附加信息-使用MSBuild 3.5将允许您从.sln文件中获取目标输出,而MSBuild 2.0中不会返回此信息(尽管我认为它在两个版本中都适用于.csproj文件)。您可以将输出(您的构建文件)用作单元测试框架的输入。

Adam Straughan 17 年前

让csproj文件保持原样(正如你所说,你不理解它)。

创建自己的msbuild-proj文件,并通过msbuild任务从主构建文件调用csproj(或sln)。告诉您的CI服务器构建您的构建文件。

这种分离使您更容易添加自己的前后任务(单元测试、冒烟测试SQL脚本、fxcop/其他静态分析等),并且不会破坏您的工作环境。这也意味着你可以在任何你想要的地方(msbuild/ant等)做你的自定义目标。看看codeplex上的MSBuildContrib,以获得额外的好处。

您不需要在构建服务器上使用可视化stuido(除非您有部署项目,除非自上次查看以来也有更改)

bh213 17 年前

创建自己的项目文件(任何以*proj结尾的文件都被MSBuild视为项目文件),并从那里调用您的构建。这样地:

<MSBuild Projects="MySolution.sln" Targets="Clean; Rebuild" Properties="Configuration=$(BuildMode);">

请注意,msbuild也可以在不做任何更改的情况下构建.sln(解决方案文件),这通常比拥有一堆csproj文件更容易。..

pero 17 年前

我同时使用NAnt和MSBuild。NAnt已升级为 NAntContrib 所以我得到了 msbuild taks。我可能是临时设置,但到目前为止,我还没有遇到重大问题。也就是说,我也不会创建新的csproj文件,因为我使用的csproj/sln与我在VS2008中使用的相同。使用msbuild构建项目大大简化了遗留的NAnt脚本(我们使用 csc 任务)。

笔记:

如果使用Windows工作流在你的项目基础上,你会建造这样的建筑有重大困难没有msbuild的项目。
不要在构建计算机上安装VS.NET。您可以使用 Wix 创建安装msi。
@Franci Penov:运行单元测试应该是每个构建的一部分。你真的想等到明天再找虫子吗?还有一个附带说明:单元测试应该运行得非常快。

Franci Penov 17 年前

我个人认为使用.csproj文件是可以的。如果滚动自己的MSBuild项目,其中没有那么多事情是你不必自己添加的。

但是,无论您决定走哪条路,我仍然建议不要将MbUnit作为构建步骤的一部分添加,而是将其作为CC.Net中的一个单独步骤添加。运行单元测试应该是每日CI周期的一部分;然而,它不应该是每个构建的一部分。

Rohit 17 年前

好的,有几件事需要注意。csproj格式已从VS2005更改为VS2008。此外,如果您使用MSBuild,请记住您将无法构建.vdproj(setup)文件;为此,您需要devenv(VS可执行文件)。也就是说,您始终可以创建一个MSBuild任务,该任务调用devenv并为您构建它。

对于您的问题,是构建自己的csproj文件还是使用VS2005创建的文件,我建议您采取一条中间道路: create your own project template ,满足您的需求,让VS来处理剩下的事情。

Shrike 17 年前

使用.csproj作为msbuild的输入是可以的。你可以手动将它的任务添加到csproj中,在从VS编译时会忽略这些任务。但如果你想做一些不平凡的事情,最好创建单独的msbuild脚本。它们可以从csproj文件中引用。您查看了TFS中的MS Build Server吗? 它与TFS的SourceControl集成,可用于CI。它的项目文件是msbuild脚本。

如果我确实使用了nAnt,是否需要在服务器上安装VS? 你是说“MSBuild”吗?不,使用msbuild和csproj文件不一定需要安装VS。