MSBuild——使用 .csproj 文件还是自己创建？
好吧，所以我很乐意承认在持续集成方面我是一个新手。
话虽这么说，我正在尝试设置 CC.NET 环境来进行自我教育，但我无法找到设置自动构建部分所需的信息。
据我了解，在 C# 中，VS 2005 及其后续版本生成的 .csproj 文件是一个有效的 MSBuild 文件。 也就是说，我已经能够使用 .csproj 文件将 MSBuild 任务集成到 CC.NET 中，但是我遇到了一些问题：
- 这里发生了很多事情，我不确定我是否真的需要自动化构建环境。
- 我没有创建这个文件。 我不明白，这让我感到害怕。 （巧合编程）
- 大多数正在发生的事情似乎都是抽象的通过
$(MSBuildToolsPath)\Microsoft.CSharp.targets - 作为 1、2 和 3 的结果，修改文件以包含 MbUnit 之类的内容似乎很复杂，而且比实际需要的更困难。 我唯一真正的选择是将其包含在 AfterBuild 部分中，这对我来说似乎有点像黑客。
那么，有几个问题要问 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：我更新了文本，使其更加简洁，并解决了我在答案中遇到的一些挥之不去的问题。
OK, so I readily concede that I'm a newbie when it comes to continuous integration.
That being said, I'm trying to set up a CC.NET environment to educate myself, but I'm having trouble finding the information I need to get the automated build portion set up.
As I understand it, in C# the .csproj file produced by VS 2005 and forward is a valid MSBuild file. To wit, I've been able to integrate the MSBuild task into CC.NET using the .csproj file, but I have a few issues with this:
- There's a lot going on in here that I'm not sure I really need in an automated build environment.
- I didn't create this file. I do not understand it, and that scares me. (Programming By Coincidence)
- Most of what is going on seems to be abstracted through
$(MSBuildToolsPath)\Microsoft.CSharp.targets - As a result of 1, 2, and 3, modifying the file to include something like MbUnit seems convoluted and more difficult than it needs to be. My only real option is to include it in the
AfterBuildsection, which seems kind of like a hack to me.
So, a few questions for the CC.NET folks, the MSBuild folks, and the MbUnit folks.
- When using MSBuild, is it advisable to use the VS-generated .csproj file as the build file? Or should I create my own?
- Should MbUnit tests be part of the MSBuild file or the CC.NET file? My research seems to suggest that they belong in the MSBuild file. If that is the case, do I create a new MSBuild .proj file and check that in to CVS in addition to the .csproj file? Or does the MbUnit task become part of my .csproj file?
- Similar to question 2. If I add the MbUnit tests to the MSBuild file and end up using the .csproj file, is the
Target Name="AfterBuild"really the section to add that information? Shouldn't there be aTarget Name="Test"section? Using the VS generated .csproj file seems to prevent the second option.
I know there's a lot there, but most of what I've been able to find online assumes a certain level of familiarity with these topics that I just don't have -- unless I'm mistaken, the learning curve for this stuff isn't a curve at all, it's a step function. :)
Edit 1: I updated the text to be a bit more concise and to address some lingering questions I've had with the answers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
我建议使用生成的 .csproj 文件 - 事实上对于生产，我认为使用生成的 .sln 文件是一个好主意。 我发现通过使用与开发人员相同的解决方案文件，您将受益匪浅。
请注意，.sln 文件实际上并不是有效的 msbuild 项目文件 - 当它们用作输入时，它们会由 msbuild 本身转换为 msbuild 项目。 棘手！
出于学习目的，您可能需要记录 .csproj 的构建并逐步了解正在发生的情况。 不过，MSBuild 比 nant 更具声明性，因此请花点时间进行一些实验。
最后，我会将您的 .sln 或 .csproj 文件包装在一个连续构建脚本项目中，并使用 msbuild 任务来构建您的项目并一起运行单元测试。 这样，开发人员不必在每次构建时都运行单元测试 - 但每次集成代码时，单元测试都会运行。 是的，确保他们跑得快！ 任何需要超过一秒的事情都应该在计划的（每晚？）构建期间运行。 如果它们花费的时间超过一秒，那么它们可能会减少单元测试，而会增加使用单元测试框架编写的集成测试。
编辑：我发现一些附加信息很有用 - 使用 MSBuild 3.5 将允许您从 .sln 文件获取目标输出，而 MSBuild 2.0 中不会返回此信息（尽管我认为它应该适用于两个版本中的 .csproj 文件）。 您可以使用输出（您构建的文件）作为单元测试框架的输入。
I would recommend using the generated .csproj files - in fact for production, I think using the generated .sln files is a good idea. I have found that you will you gain by using the same solution files as the developers.
Be aware that .sln files are not actually valid msbuild project files - they are transformed into msbuild projects by msbuild itself when they are used as inputs. Tricky!
For learning purposes, you may want to log the build of a .csproj and step through to get an idea of what is going on. MSBuild is a bit more declarative than nant though, so take your time and experiment a bit.
Finally, I would wrap your .sln or .csproj files in a continuous build script project with msbuild tasks to build your projects and run your unit tests together. This way the developers don't have to run the unit test every time they build - but every time they integrate their code the unit tests will run. And yes, make sure they run fast! Anything that takes more than a second should be run during a scheduled (nightly?) build instead. Likely they are less unit tests and more integration tests written with a unit test framework if they take more than a second.
Edit: Some addition information I have found that I have found useful - using MSBuild 3.5 will allow you to get the target output from a .sln file, while this information is not returned in MSBuild 2.0 (though I think it should work for .csproj files in both versions). You can use the output (your built files) as inputs to your unit testing framework.
不要管 csproj 文件（正如你所说，你不明白它）。
创建您自己的 msbuild proj 文件，并通过 msbuild 任务从主构建文件调用 csproj（或 sln）。 告诉你的 CI 服务器构建你的构建文件。
这种分离使您可以更轻松地添加自己的前置和后置任务（单元测试、冒烟测试 SQL 脚本、fxcop/其他静态分析等），并且不会破坏您的工作环境。 这也意味着您可以按照您的意愿（msbuild/ant 等）执行自定义目标。请查看 codeplex 上的 MSBuildContrib，以获得额外的好处。
您的构建服务器上不需要 Visual Stuido（除非您有部署项目，除非自我上次查看以来这也已更改）
Leave the csproj file well alone (as you say, you don't understand it).
Create your own msbuild proj file and call the csproj (or sln) from your main build file via the msbuild task. Tell your CI server to build your build file.
This seperation makes it easier to add your own pre and post tasks (unit tests, smoke testing SQL scripts, fxcop/other static analysis, etc.) and you won't break your working environment. It also means you can do your custom targets in whatever you wish (msbuild/ant, etc.) Have a look as MSBuildContrib on codeplex for extra goodness.
You don't need visual stuido on your build server (unles you have deployment projects, unless this has also been changed since I last looked)
创建您自己的项目文件（任何以 *proj 结尾的内容都被 MSBuild 视为项目文件）并从那里调用您的构建。 像这样：
请注意，msbuild 也可以构建 .sln（解决方案文件）而不进行任何更改，这通常比拥有一堆 csproj 文件更容易......
Create your own project file (anything that ends with *proj is considered a project file by MSBuild) and call your build from there. Like this:
Note that msbuild can also build .sln (solution file) without any changes, which is usually easier than having a bunch of csproj files...
我同时使用 NAnt 和 MSBuild。 NAnt 已使用 NAntContrib 进行升级，因此我得到了 msbuild 任务。 我可能是临时设置，但到目前为止我还没有遇到重大问题。 也就是说，我也没有创建新的 csproj 文件，因为我使用与 VS2008 中使用的相同的 csproj/sln。
使用 msbuild 构建项目大大简化了旧版 NAnt 脚本（我们使用 csc< /a> 任务）。
注意：
您将在您的项目中奠定基础
有重大困难建立这样的
没有 msbuild 的项目。
I use both NAnt and MSBuild. NAnt was upgraded with NAntContrib so that I got msbuild taks. I may be temporary setup but so far I have not run in major problems. That said I also do not create a new csproj file because I use the same csproj/sln that I use in VS2008.
Building projects with msbuild greatly simplified legacy NAnt scripts (we used csc task).
Notes:
Foundation in your projects you will
have major difficulties build such
project without msbuild.
我个人认为使用 .csproj 文件就可以了。 如果您滚动自己的 MSBuild 项目，那么其中没有太多内容是您不需要自己添加的。
然而，无论您决定采用哪种方式，我仍然建议不要将 MbUnit 添加为构建步骤的一部分，而是将其添加为 CC.Net 中的单独步骤。 运行单元测试应该是日常 CI 周期的一部分； 但是，它不应该成为每个构建的一部分。
I personally think it's ok to go with the .csproj file. There's not that much going on in there that you wouldn't have to add yourself if rolling your own MSBuild project.
However, whatever route you decide to go, I'd still recommend to not add the MbUnit as part of your build step, but add it as a separate step in CC.Net. Running unit tests should be part of the daily CI cycle; however, it should not be part of every build.
好的，有几点需要注意。 csproj 格式已从 VS2005 更改为 VS2008。 另外，如果您要使用 MSBuild，请记住您将无法构建 .vdproj（安装）文件； 为此，您需要 devenv（VS 可执行文件）。 也就是说，您始终可以创建一个 MSBuild 任务，该任务调用 devenv 并为您构建它。
至于你的问题是构建自己的csproj文件还是使用VS2005创建的文件，我建议采取中间道路： 创建您自己的项目模板，它可以满足您的需求，让 VS 处理其余的事情。
OK, few things to watch out for. The csproj format has changed from VS2005 to VS2008. Also if you are going with MSBuild, remember that you won't be able to build .vdproj (setup) files; for that you need devenv (the VS executable). That said you can always create a MSBuild task which calls devenv and builds it for you.
As for your question whether to build your own csproj file or use the one created by VS2005, I would suggest a middle road: create your own project template, which caters to your needs and let VS take care of the rest.
可以使用 .csproj 作为 msbuild 的输入。 您可以手动将其任务添加到 csproj 中，这些任务在从 VS 编译期间将被忽略。 但如果您要制作一些重要的东西，最好创建单独的 msbuild 脚本。 并且可以从 csproj 文件中引用它们。
您是否看过 TFS 的一部分 MS Build Server？
它与 TFS 的 SourceControl 集成，可用于 CI。 它的项目文件是msbuild脚本。
It's ok to use .csproj as input for msbuild. You can manually add tasks for it into csproj which will be ignored during compliting from VS. But if you're going to make some non trivial stuff it's better to create separate msbuild's scripts. And they can be referenced from csproj files.
Did you have a look at MS Build Server which is part of TFS?
It integrates with TFS's SourceControl and could be used for CI. Its project files are msbuild scripts.