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

Question

好的，因此，我很容易承认自己在持续集成方面是新手。

话虽这么说，我试图建立一个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文件。如果是这样，我是否要创建一个新的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项目。整rick

出于学习目的，您可能希望记录.csproj的生成并逐步进行以了解发生了什么。尽管MSBuild比nant更具声明性，所以花点时间尝试一下。

最后，我将您的.sln或.csproj文件包装在带有msbuild任务的连续构建脚本项目中，以构建您的项目并一起运行单元测试。这样，开发人员不必在每次构建时都运行单元测试-但每次他们集成代码时，单元测试都将运行。是的，请确保它们运行速度快!超过一秒钟的时间都应该在计划的(每晚？)构建期间运行。如果它们花费的时间超过一秒钟，那么它们可能是较少的单元测试，而更多的是使用单元测试框架编写的集成测试。

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