您在哪里放置所有解决方案级别(全局)任务？在一个专门用于此目的的空白项目？

Question

当有人构建我的解决方案时,我想要运行多个任务,具体取决于解决方案配置:

• 在Release配置中,为整个解决方案运行Doxygen(doxygen.exe ....)
• 在Debug和Release配置中,为整个解决方案运行StyleCop(调用StyleCop目标)
• 在Debug配置中,为整个解决方案运行FxCop(fxcop.exe ...)
• 和更多

这些都是解决方案级别(全局)任务,因此将它放在每个项目文件中都没有意义.这似乎是一个常见的问题,所以你如何处理它？

我想我可以创建一个空项目,确保每个其他项目都依赖于它并将所有解决方案级别的任务放在那个......？

Answer 1

我更喜欢将此类任务放在 .targets 文件中，并从我的主要项目（大致是不生成库的项目）中引用它们。我还可以在该 .targets 文件中创建Targets，该文件将组合常见任务的子集。这样，我的一些项目可以方便地运行sharedtask1and sharedtask2，而其他项目则运行sharedtask1and sharedtask3，因为我只是添加DependsOnTargets="Shared12"and DependsOnTargets="Shared13"（显然，我会尝试选择描述性名称）。

这些文章提供了一些关于组织 msbuild 任务的好建议：

创建可靠构建的最佳实践，第 1 部分

创建可靠构建的最佳实践，第 2 部分

编辑

要仅运行某些任务一次，请使用上面第二篇文章中所述的增量构建：

• 在我上面提到的通用 .targets 文件中，创建一个任务，将所有文件作为输入，将一些虚拟标记文件作为输出。
• 使该任务执行您感兴趣的实际工作并更新标记文件。
• 使您的所有项目都依赖于新创建的任务

构建解决方案时，第一个项目将启动上述任务，该任务将输出一个标记文件，并且只要您的输入文件在构建的其余部分中没有更改，该任务就不会再次运行。现在，这样做的缺点是

• 如果您的构建导致过程中生成或更改文件，则该任务将运行多次
• 即使您只构建单个项目，该任务也会运行。如果您正在生成文档，这实际上可能是“正确”的行为。如果你想避免这种情况，我认为你必须真正调整你的 msbuild 文件，但我的印象是，这就是你想要避免的。
• 该任务将在构建之前运行，因此任何依赖于要构建的程序集版本的任务都将不走运

要解决最后一个问题，您必须放弃从 VS 进行构建，而是调用自定义任务，该任务将构建解决方案，然后使用命令行中的 msbuild.exe 按顺序执行一个或多个自定义任务。我意识到这可能不是您正在寻找的开发人员体验。