创建自定义任务时如何访问 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)
设计决策(构建无法看到详细信息)背后的原因如下:
(1)构建过程不应假设用户(以及她选择的记录器)想要什么。它们不一定属于同一个人所有。考虑构建一个任务了解详细信息并且仅以诊断详细信息记录某些信息的构建。您希望在控制台上以安静的冗长方式进行构建,但还要附加一个数据库记录器来记录所有内容。你不能,因为任务从未触发事件,因为它看到了安静的冗长。
(2) 重要性和冗长性会混淆。重要性是构建过程暗示记录器(具有特定的详细程度)可能希望对事件执行哪些操作。它们存在于不同的领域:任务和构建过程中的重要性,仅记录器中的详细程度。
(3) 详细程度本身(例如/verbosity)只是一个默认值。记录器通常允许您为其指定特定的详细程度。例如 /fileloggerparameters:verbosity=detailed。任务应该得到哪个?可能有几个。
话虽如此,回想起来,有一个很好的理由重新审视这一点。这是因为在 Log 对象上触发大量事件(您可能会合理地进行诊断)可能会显着影响构建性能,即使在较低的详细程度(它们被记录器丢弃)下也是如此。为了解决这个问题,我们应该允许构建过程至少知道它是否处于某种“超级详细”模式,在这种模式下可以安全地疯狂记录。
此外,最终重要的是完成你的工作。所以也许所有这些细节都让事情变得过于复杂。
丹——几年前我帮助设计了这个。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
我认为事情并非如此。您可以通过 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.