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

Question

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

话虽这么说,我正在尝试建立一个CC.NET环境来教育自己,但是我很难找到设置自动构建部分所需的信息.

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

1. 这里有很多事情,我不确定我是否真的需要在自动构建环境中.
2. 我没有创建这个文件.我不明白,这吓到我了.(巧合编程)
3. 大部分正在发生的事情似乎都是通过抽象的 $(MSBuildToolsPath)\Microsoft.CSharp.targets
4. 作为1,2和3的结果,修改文件以包含类似MbUnit的东西似乎令人费解并且比它需要的更难.我唯一真正的选择是把它包含在这个AfterBuild部分中,这对我来说似乎有点像黑客.

所以,CC.NET人员,MSBuild人员和MbUnit人员的一些问题.

1. 使用MSBuild时,建议使用VS生成的.csproj文件作为构建文件吗？或者我应该创建自己的？
2. MbUnit测试应该是MSBuild文件还是CC.NET文件的一部分？我的研究似乎表明它们属于MSBuild文件.如果是这种情况,我是否创建一个新的MSBuild .proj文件并检查除了.csproj文件之外的CVS？或者MbUnit任务是否成为我的.csproj文件的一部分？
3. 与问题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两个版本中的文件).您可以使用输出(构建的文件)作为单元测试框架的输入.