我前一个问题的合理跟进：“How to check all projects in solution for some criteria?” 我得到了很好的答案，使用CustomAfterMicrosoftCommonTargets，CustomBeforeMicrosoftCommonTargets。他们确实有效，所以我决定不要停在中间。
问题是我不想要机器范围的任务。对我来说这不是一个好主意（它会影响其他版本。确定，这可以处理，但仍然可以），也不是我的队友（我不想让他们在系统文件夹中添加内容......），也不是用于构建服务器。 需要什么：使用Visual Studio或MSBuild从干净机器上的源代码控制中从头开始构建解决方案。
Custom * MicrosoftCommonTargets似乎是常规属性。
那么，如何指定这个属性？从命令行设置它时，它工作得很好。 这很奇怪，但看起来这里有一点魔法：作为命令行参数传递给一个构建的属性传递传递给所有嵌套构建！
这对于构建服务器来说很好。但这不适用于Visual Studio构建。甚至声明解决方案级属性也无济于事：静态属性和动态属性都不会转移到嵌套构建。
...我有一个hacky想法在解决方案构建之前设置环境变量并在之后擦除它。但我不喜欢它。有更好的想法吗？
答案 0 :(得分：0)
我使用了与@Spider M9不同的技术。我希望解决方案树中的所有项目/当前目录中的所有子目录都使用扩展构建抛出Custom * MicrosoftCommonTargets。我不喜欢被迫改变每个新项目来导入自定义目标/道具。
我在根目录中放置了特殊文件，比如说 msbuild.include ，每个项目的自定义目标加载器都试图在中找到它。， .. \ ， .. \ .. \ ，等等。 msbuild.include包含触发自定义操作执行的标志。如果加载程序找不到此文件，则会禁用加载所有自定义目标和停止。这使我能够将我的构建扩展与工作存储库中的项目一起使用，而不是与开源项目一起使用。
如果您对我感兴趣，我可以发布装载机。这是一个非常简单和优雅的解决方案。
例如，我可以使用我的密钥在所有子文件夹中的所有项目中签署任何程序集。
答案 1 :(得分：-1)
我总是设置每个项目来导入标准的.props文件。使用GetDirectoryNameOfFileAbove属性函数（请参阅MSDN）来查找它。将此作为每个项目文件的第一行。建立后，您可以从该文件重定向到其他导入。另一个技巧是使标准导入（显然在版本控制下）有条件地导入另一个.props文件，只有它存在。此可选文件不在版本控制中，但可供任何开发人员使用自己的私有/临时属性或其他行为进行创建和修改。