4

我之前的问题的逻辑跟进：“如何检查解决方案中的所有项目是否符合某些标准？ ”
使用 CustomAfterMicrosoftCommonTargets、CustomBeforeMicrosoftCommonTargets 给了我一个很好的答案。他们确实有效，所以我决定不中途停下来。

问题是我不想要机器范围的任务。这对我（它会影响其他构建。当然，这可以处理，但仍然）和我的队友（我不想让他们在系统文件夹中放一些东西......）都不是一个好主意，也不是用于构建服务器。需要什么：在干净的机器上使用 Visual Studio 或 MSBuild 从头开始​​构建解决方案。

看来 Custom*MicrosoftCommonTargets 是常规属性。

那么，如何指定这个属性呢？从命令行设置它时效果很好。这很奇怪，但这里似乎有一点魔力：作为命令行参数传递给一个构建的属性被传递给所有嵌套构建！

这对于构建服务器来说很好。但这不适用于 Visual Studio 构建。甚至声明解决方案级别的属性也无济于事：静态属性和动态属性都不会转移到嵌套构建中。

...我有一个 hacky 想法，即在解决方案构建之前设置环境变量并在之后将其删除。但我不喜欢它。有更好的想法吗？

4

2 回答 2

0

我使用与@Spider M9 不同的技术。我希望解决方案树中的所有项目/当前目录中的所有子目录都使用扩展构建抛出 Custom*MicrosoftCommonTargets。我不喜欢被迫更改每个新项目以导入自定义目标/道具。

我将特殊文件，比如说msbuild.include放在根目录中，我的每个项目的自定义目标加载器都试图在. , ..\ , ..\..\等等。msbuild.include 包含触发执行自定义操作的标志。如果加载程序找不到此文件，它将禁用加载所有自定义目标和停止。这使我能够将我的构建扩展与工作存储库中的项目一起使用，而不是与开源项目一起使用。

如果你有兴趣我可以发布加载器。这是一个非常简单而优雅的解决方案。

例如，我可以用我的密钥签署所有子文件夹中所有项目中的任何程序集。

于 2011-04-21T06:05:25.510 回答
-1

我总是将每个项目设置为导入标准的 .props 文件。使用 GetDirectoryNameOfFileAbove 属性函数（请参阅 MSDN）找到它。将此作为每个项目文件的第一行。建立后，您可以从该文件重定向到其他导入。另一个技巧是让标准导入（显然是在版本控制下）有条件地导入另一个 .props 文件，前提是它存在。此可选文件不受版本控制，但可供任何开发人员使用他们自己的私有/临时属性或其他行为创建和修改。

于 2011-04-21T01:08:25.593 回答