21

好的，所以我欣然承认在持续集成方面我是新手。

话虽如此，我正在尝试设置一个 CC.NET 环境来教育自己，但我无法找到设置自动构建部分所需的信息。

据我了解，在 C# 中，由 VS 2005 和转发生成的 .csproj 文件是有效的 MSBuild 文件。也就是说，我已经能够使用 .csproj 文件将 MSBuild 任务集成到 CC.NET 中，但是我对此有一些问题：

  1. 这里发生了很多事情，我不确定我是否真的需要在自动构建环境中。
  2. 我没有创建这个文件。我不明白，这让我害怕。（巧合编程）
  3. 大多数正在发生的事情似乎都是通过抽象的$(MSBuildToolsPath)\Microsoft.CSharp.targets
  4. 作为 1、2 和 3 的结果，修改文件以包含 MbUnit 之类的内容似乎很复杂，而且比它需要的更困难。我唯一真正的选择是将它包含在该AfterBuild部分中，这对我来说似乎有点像 hack。

所以，有几个问题要问 CC.NET 人员、MSBuild 人员和 MbUnit 人员。

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

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

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

4

7 回答 7

13

我建议使用生成的 .csproj 文件——事实上，对于生产，我认为使用生成的 .sln 文件是个好主意。我发现您将通过使用与开发人员相同的解决方案文件来获得收益。

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

出于学习目的，您可能需要记录 .csproj 的构建并逐步了解正在发生的事情。MSBuild 虽然比 nant 更具声明性，所以花点时间进行一些实验。

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

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

于 2008-10-21T21:39:04.643 回答
4

将 csproj 文件单独放置（如您所说，您不了解它）。

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

这种分离可以更轻松地添加您自己的前后任务（单元测试、冒烟测试 SQL 脚本、fxcop/其他静态分析等），并且不会破坏您的工作环境。这也意味着您可以按照自己的意愿（msbuild/ant 等）执行自定义目标。看看 codeplex 上的 MSBuildContrib 以获得额外的好处。

您的构建服务器上不需要visual stuido（除非您有部署项目，除非自从我上次查看以来这也已更改）

于 2008-10-20T23:05:44.127 回答
3

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

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

请注意，msbuild 也可以在不进行任何更改的情况下构建 .sln（解决方案文件），这通常比拥有一堆 csproj 文件更容易......

于 2008-10-21T08:14:48.743 回答
2

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

笔记：

  1. 如果您在项目中使用 Windows Workflow Foundation，那么在没有 msbuild 的情况下构建此类项目会遇到很大困难。
  2. 不要在构建机器上安装 VS.NET。您可以使用Wix创建安装 msi。
  3. @Franci Penov：运行单元测试应该是每个构建的一部分。你真的要等到明天再找bug吗？附带说明：单元测试应该运行得非常快。
于 2008-10-21T19:16:52.760 回答
1

我个人认为使用 .csproj 文件是可以的。如果滚动您自己的 MSBuild 项目，那么您不必添加自己的内容。

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

于 2008-10-20T22:33:32.100 回答
0

可以使用 .csproj 作为 msbuild 的输入。您可以手动将任务添加到 csproj 中，在从 VS 编译期间将被忽略。但是，如果您要制作一些重要的东西，最好创建单独的 msbuild 脚本。并且可以从 csproj 文件中引用它们。您是否看过作为 TFS 一部分的 MS Build Server？它与 TFS 的 SourceControl 集成，可用于 CI。它的项目文件是 msbuild 脚本。

如果我确实使用了nAnt，是否需要在服务器上安装VS？您的意思是“MSBuild”吗？不，不一定要安装 VS 才能将 msbuild 与 csproj 文件一起使用。

于 2008-10-20T22:23:13.587 回答
0

好的，需要注意的事项很少。csproj 格式已从 VS2005 更改为 VS2008。此外，如果您使用 MSBuild，请记住您将无法构建 .vdproj（设置）文件；为此，您需要 devenv（VS 可执行文件）。也就是说，您始终可以创建一个调用 devenv 并为您构建它的 MSBuild 任务。

至于您的问题是构建自己的csproj文件还是使用VS2005创建的文件，我建议中间道路：创建自己的项目模板，满足您的需求，让VS负责其余的工作。

于 2008-10-20T23:28:01.523 回答