如何在 Visual Studio 构建中模拟 /p msbuild 参数？
这是我上一个问题的逻辑后续：“
问题是我不想要机器范围的任务。这对我来说都不是一个好主意（它会影响其他构建。当然，这可以处理，但仍然），对我的队友来说也不是一个好主意（我不想让他们在系统文件夹中放入一些东西......），也不是用于构建服务器。 需要什么：使用 Visual Studio 或 MSBuild 在干净的计算机上从源代码控制中从头开始构建的解决方案。
看来 Custom*MicrosoftCommonTargets 是常规属性。
那么，如何指定这个属性呢？当从命令行设置它时它工作得很好。 这很奇怪，但似乎这里存在一点魔力：作为命令行参数传递到一个构建的属性会传递传递给所有嵌套构建！
这对于构建服务器来说很好。但这不适用于 Visual Studio 构建。即使声明解决方案级属性也无济于事：静态属性和动态属性都不会转移到嵌套构建。
...我有一个奇怪的想法，在解决方案构建之前设置环境变量并在之后删除它。但我不喜欢它。还有更好的想法吗？
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我使用了与@Spider M9 不同的技术。我希望解决方案树/当前目录中的所有子目录中的所有项目都使用扩展构建抛出 Custom*MicrosoftCommonTargets。我不喜欢被迫更改每个新项目以导入自定义目标/道具。
我将特殊文件（例如 msbuild.include）放在根目录中，每个项目的自定义目标加载器都会尝试在 .、..\ 、..\..\ 等等。 msbuild.include 包含触发执行自定义操作的标志。如果加载程序找不到此文件，它将禁用加载所有自定义目标和停止点。这使我能够将构建扩展与工作存储库中的项目一起使用，而不是与开源项目一起使用。
如果您有兴趣我可以发布加载程序。这是一个非常简单而优雅的解决方案。
例如，我可以使用我的密钥对所有子文件夹中所有项目中的任何程序集进行签名。
I use a bit different technique then @Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
我总是将每个项目设置为导入标准 .props 文件。使用 GetDirectoryNameOfFileAbove 属性函数（请参阅 MSDN）来查找它。将其作为每个项目文件的第一行。一旦建立，您可以从该文件重定向到其他导入。另一个技巧是让标准导入（显然是在版本控制下）有条件地导入另一个 .props 文件（仅当它存在时）。此可选文件不会受到版本控制，但任何开发人员都可以使用自己的私有/临时属性或其他行为来创建和修改。
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.