MSBuild文件VS SLN和Project文件

Question

我刚刚开始关注MSBuild并全面了解整个想法。我已经使用Hudson设置了CI服务器，并想知道我应该如何“处理”构建脚本和sln / proj文件。

例如，我有一个现有的解决方案，其中包含10个项目（一个是网站，另一个是Web部署项目，以及设置MSI项目）。处理这个问题的好方法是什么？

1. 我应该在sln文件中指出msbuild吗？
2. 我应该采用SLN文件中的内容并创建另一个文件，以便指向不同的proj文件吗？
3. 我应该从所有sln和proj文件中获取代码并创建一个自定义构建脚本吗？

如果我做最后两个中的任何一个，我是否要担心维护两组脚本，即确保我的脚本是最新的以及sln / proj文件？

在本地盒子上开发时，如何处理它？我只是按CTRL移动B来构建它，然后只使用构建脚本进行CI服务器/部署构建吗？

Answer 1

创建运行MSBuild任务的构建脚本。将MSbuild任务指向您的解决方案或项目。编译源代码然后变得简单，只是另一项任务。你的构建脚本如果可以自由地专注于更大更好的东西。

您的CI服务器将运行您的构建脚本。要在本地计算机上运行构建，请在项目中包含.bat文件。 .bat文件调用MSBuild来运行构建脚本，并为生成日志文件等事项设置命令行选项。然后，您可以双击bat文件并查看日志文件以查看结果。这是一个例子：

%WINDIR%\Microsoft.NET\Framework\v3.5\MSBuild.exe build.xml /fileLogger /fileLoggerParameters:LogFile=MSBuildLog.txt

Answer 2

我一直在谷歌搜索并找到杰夫关于“F5”的帖子：

http://blog.codinghorror.com/the-f5-key-is-not-a-build-process/

从这篇以及其他几篇文章中我决定最好创建一个独立于SLN和项目文件的MSBuild脚本。

SCOTT HANSELMAN（Scott's Blog）有一个关于在VS中创建快捷方式以运行构建脚本的良好链接。 blog entry about parallel building

我假设您仍然需要按F5进行调试，并且无法在大多数情况下避免这种情况，（asp.net可以附加到进程，因此您不必继续这样做。）

我将首先查看项目文件并从中构建脚本，然后在之后进行自定义以适应。

希望这可能有助于将来环顾四周的其他人。

Answer 3

我倾向于喜欢这种方法，每个项目都有自己的构建文件（无论是msbuild还是NAnt等），然后有一个构建所有项目的主构建。这样你就可以专注于项目（例如在修复bug时），并在签入之前运行master build，而master.build就是在构建机器上运行的。

您仍然可以在VS中正常构建和调试，构建脚本是独立的。构建脚本仅适用于构建框，并且在签入之前运行。

这只是我对事物的看法。您可以在getting started with CI上发现我的帖子很有用......

祝你好运！