Question

好的，所以我很容易承认，在持续集成方面，我是新手。

话虽这么说，我正在尝试建立一个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文件。如果是这种情况，我是否创建一个新的MSBuild .proj文件并检查除了.csproj文件之外的CVS？或者MbUnit任务是否成为我的.csproj文件的一部分？
与问题2类似。如果我将MbUnit测试添加到MSBuild文件并最终使用.csproj文件，Target Name="AfterBuild"真的是添加该信息的部分吗？不应该有Target Name="Test"部分吗？使用VS生成的.csproj文件似乎阻止了第二个选项。

我知道那里有很多东西，但我在网上找到的大部分内容都假定我对这些主题有一定程度的熟悉程度 - 除非我弄错了，学习曲线为这个东西根本不是曲线，它是一个阶梯函数。：）

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

Answer 1

我建议使用生成的.csproj文件 - 实际上用于生产，我认为使用生成的.sln文件是一个好主意。我发现使用与开发人员相同的解决方案文件可以获得收益。

请注意.sln文件实际上并不是有效的msbuild项目文件 - 当它们用作输入时，它们会被msbuild本身转换为msbuild项目。棘手！

出于学习目的，您可能希望记录.csproj的构建并逐步了解以了解正在发生的事情。虽然MSBuild比nant更有说服力，所以请花点时间和实验。

最后，我将.sln或.csproj文件包装在带有msbuild任务的连续构建脚本项目中，以构建项目并一起运行单元测试。这样开发人员不必每次构建时都运行单元测试 - 但每次集成代码时，单元测试都会运行。是的，确保他们跑得快！任何需要超过一秒的东西应该在预定的（每晚？）构建期间运行。可能它们的单元测试较少，并且如果它们花费的时间超过一秒，则会使用单元测试框架编写更多的集成测试。

编辑：我发现有些附加信息我发现有用 - 使用MSBuild 3.5将允许您从.sln文件获取目标输出，而MSBuild 2.0中不返回此信息（虽然我认为它应该适用于两个版本中的.csproj文件）。您可以使用输出（构建的文件）作为单元测试框架的输入。

Answer 2

单独保留csproj文件（如你所说，你不明白）。

创建自己的msbuild proj文件，并通过msbuild任务从主构建文件中调用csproj（或sln）。告诉您的CI服务器构建您的构建文件。

这种分离使您可以更轻松地添加自己的前期和后期任务（单元测试，冒烟测试SQL脚本，fxcop /其他静态分析等），您不会破坏您的工作环境。这也意味着你可以随心所欲地完成你的自定义目标（msbuild / ant等）。在codeplex上看看MSBuildContrib，以获得额外的好处。

你的构建服务器上不需要visual stuido（unles你有部署项目，除非我上次查看时也改变了）

Answer 3

创建您自己的项目文件（以* proj结尾的任何内容都被MSBuild视为项目文件）并从那里调用您的构建。像这样：

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

请注意，msbuild还可以构建.sln（解决方案文件）而无需任何更改，这通常比拥有一堆csproj文件更容易......

Answer 4

我同时使用NAnt和MSBuild。 NAnt已升级为NAntContrib，因此我获得了msbuild次。我可能是临时设置，但到目前为止我没有遇到重大问题。也就是说我也没有创建一个新的csproj文件，因为我使用的是与我在VS2008中使用的相同的csproj / sln。使用msbuild构建项目大大简化了传统的NAnt脚本（我们使用了csc任务）。

注意：

如果您使用Windows Workflow 你将在你的项目中取得基础建立这样的主要困难没有msbuild的项目。
不要在构建计算机上安装VS.NET。您可以使用Wix创建安装msi。
@Franci Penov：运行单元测试应该是每个构建的一部分。你真的想等到明天找到一个bug吗？有一个附注：单元测试应该运行得非常快。

Answer 5

我个人认为可以使用.csproj文件。那里没有那么多，你不必在添加自己的MSBuild项目时添加自己。

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

Answer 6

可以使用.csproj作为msbuild的输入。您可以手动将任务添加到csproj中，在从VS进行压缩时将忽略该任务。但是如果你要做一些非常重要的事情，最好创建单独的msbuild脚本。它们可以从csproj文件中引用。您是否看过作为TFS一部分的MS Build Server？它与TFS的SourceControl集成，可用于CI。它的项目文件是msbuild脚本。

如果我确实使用过nAnt，是否必须在服务器上安装VS？你的意思是'MSBuild'吗？不，不一定要安装VS以使用带有csproj文件的msbuild。

Answer 7

好的，很少有事情需要注意。 csproj格式已从VS2005更改为VS2008。此外，如果您使用MSBuild，请记住您将无法构建.vdproj（安装）文件;因为你需要devenv（VS可执行文件）。这就是说你总是可以创建一个调用devenv的MSBuild任务并为你构建它。

关于你是建立自己的csproj文件还是使用VS2005创建的文件的问题，我建议你选择一条中间道路：create your own project template，它可以满足你的需求，让VS负责其余的事情。< / p>

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

7 个答案: