创建自定义任务时如何访问 MSBuild 详细信息？
在创建自定义 Microsoft.Build.Utilities.Task 的上下文中，如何访问 MSBuild 详细信息？
Microsoft.Build.Utilities.Task： http:// msdn.microsoft.com/en-us/library/microsoft.build.utilities.task.aspx
MSBuild 详细信息：链接
In the context of creating a custom Microsoft.Build.Utilities.Task how do I get access to the MSBuild verbosity?
Microsoft.Build.Utilities.Task: http://msdn.microsoft.com/en-us/library/microsoft.build.utilities.task.aspx
MSBuild verbosity: Link
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为事情并非如此。您可以通过 Task.BuildEngine 属性获取对构建引擎的引用。然后只需调用其LogMessageEvent即可生成消息。 BuildMessageEventArgs.Importance 根据详细程度设置确定消息是否实际上可见。这与其他日志记录 API 一致。
I don't think it works that way. You get a reference to the build engine through Task.BuildEngine property. Then simply call its LogMessageEvent to generate a message. The BuildMessageEventArgs.Importance determines whether or not the message will actually be visible, based on the verbosity setting. This is consistent with other logging APIs.
设计决策（构建无法看到详细信息）背后的原因如下：
（1）构建过程不应假设用户（以及她选择的记录器）想要什么。它们不一定属于同一个人所有。考虑构建一个任务了解详细信息并且仅以诊断详细信息记录某些信息的构建。您希望在控制台上以安静的冗长方式进行构建，但还要附加一个数据库记录器来记录所有内容。你不能，因为任务从未触发事件，因为它看到了安静的冗长。
(2) 重要性和冗长性会混淆。重要性是构建过程暗示记录器（具有特定的详细程度）可能希望对事件执行哪些操作。它们存在于不同的领域：任务和构建过程中的重要性，仅记录器中的详细程度。
(3) 详细程度本身（例如/verbosity）只是一个默认值。记录器通常允许您为其指定特定的详细程度。例如 /fileloggerparameters:verbosity=detailed。任务应该得到哪个？可能有几个。
话虽如此，回想起来，有一个很好的理由重新审视这一点。这是因为在 Log 对象上触发大量事件（您可能会合理地进行诊断）可能会显着影响构建性能，即使在较低的详细程度（它们被记录器丢弃）下也是如此。为了解决这个问题，我们应该允许构建过程至少知道它是否处于某种“超级详细”模式，在这种模式下可以安全地疯狂记录。
此外，最终重要的是完成你的工作。所以也许所有这些细节都让事情变得过于复杂。
丹——几年前我帮助设计了这个。
The reasoning behind the design decision (that the build cannot see the verbosity) is the following:
(1) The build process should not assume what the user (and the loggers she chooses) want. They are not necessarily owned by the same person. Consider walking up to a build where a task knows about verbosity and only logs certain information at diagnostic verbosity. You want to build at quiet verbosity on the console but also attach a database logger that logs absolutely everything. You can't because the task never fired the event because it sees the quiet verbosity.
(2) Importance and Verbosity would get confused. Importance is the build process's hint as to what loggers, with a particular verbosity, might want to do with the event. They exist in separate realms: Importance in the tasks and build process, Verbosity only in loggers.
(3) Verbosity itself (eg., /verbosity) is just a default value. Loggers typically allow you to specify a specific verbosity for them. For example /fileloggerparameters:verbosity=detailed. Which should the task get? There might be several.
Having said that, in retrospect there is one good reason to reexamine this. That is because firing a lot of events on the Log object, which you might reasonably do for diagnostics, can significantly affect the build performance even at lower verbosities where they're getting discarded by the logger. To fix this we should probably allow the build process to at least know whether it's in some kind of "super verbose" mode where it's safe to log like crazy.
Also, what ultimately matters is Getting Your Job Done. So perhaps all these niceties were overcomplexifying things.
Dan -- years back I helped design this.