MSBuild -- 使用 .csproj 文件还是自己创建？答案

【问题标题】：MSBuild -- Use the .csproj file or roll your own?MSBuild -- 使用 .csproj 文件还是自己创建？
【发布时间】：2010-09-18 05:13:10
【问题描述】：

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

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

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

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

所以，有几个问题要问 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：我更新了文本，使其更加简洁，并解决了我在答案中遇到的一些挥之不去的问题。

【问题讨论】：

标签： version-control msbuild continuous-integration cruisecontrol.net mbunit

【解决方案1】：

我建议使用生成的 .csproj 文件 - 事实上，对于生产，我认为使用生成的 .sln 文件是个好主意。我发现使用与开发人员相同的解决方案文件会让您受益。

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

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

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

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

【讨论】：

【解决方案2】：

别管csproj文件（如你所说，你不懂）。

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

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

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

【讨论】：

新的 .proj 文件是否与 .csproj 文件一起被检入 CVS？还是它只存在于构建服务器上和源代码控制环境之外？我倾向于检查它，但如果有最佳实践，我想遵循它们。
一切都被签入。我们使用 TeamCity 构建服务器和几个构建代理。构建服务器只知道 2 个（可以超过 2 个）的东西。源代码在哪里（cvs/svn/vss/etc）以及构建哪个文件。（低电池得省）
这也是我使用的方法。对于每个项目（网站、Web 应用程序、应用程序、扩展程序等），我在 Subversion 中都有自己的存储库，它自己的 .sln 文件包含一个或多个 .*proj 和一个 .proj 文件。 .sln 文件旨在允许人们在 VS 中打开整个内容并编写/调试代码。 .proj 文件是为了允许 CruiseControl 或 TeamCity 执行持续集成。
如前所述............创建一些文件......像......MySolution_MyMSBuildFile.msbuild（或.xml或.proj，没关系很多）。针对此脚本运行 msbuild.exe。 MySolution_MyMSBuildFile.msbuild 将调用（目标），将 .sln 或 .csproj 文件传递给它。

【解决方案3】：

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

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

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

【讨论】：

我同意。我已经在许多项目中使用了这种方法，并且似乎效果很好。

【解决方案4】：

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

注意事项：

如果您使用 Windows 工作流为您的项目奠定基础，您将有重大困难建立这样的没有 msbuild 的项目。
不要在你的构建机器上安装 VS.NET。您可以使用Wix 创建安装 msi。
@Franci Penov：运行单元测试应该是每个构建的一部分。你真的要等到明天再找bug吗？附带说明：单元测试应该运行得非常快。

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

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

至于您的问题是构建自己的csproj文件还是使用VS2005创建的文件，我建议中间道路：create your own project template，它满足您的需求，让VS处理其余的事情。

【讨论】：

【解决方案7】：

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

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

【讨论】：