在创建自定义 Microsoft.Build.Utilities.Task 的上下文中，我如何访问 MSBuild 详细信息？
Microsoft.Build.Utilities.Task：http: //msdn.microsoft.com/en-us/library/microsoft.build.utilities.task.aspx
MSBuild 详细程度：http: //blogs.msdn.com/b/saraford/archive/2008/10/07/did-you-know-you-can-configure-the-msbuild-verbosity-in-the-output-window -329.aspx
我不认为它是这样工作的。您可以通过 Task.BuildEngine 属性获得对构建引擎的引用。然后只需调用它的 LogMessageEvent 来生成消息。BuildMessageEventArgs.Importance 根据详细程度设置确定消息是否实际可见。这与其他日志记录 API 一致。
设计决策（构建无法看到详细程度）背后的原因如下：
(1) 构建过程不应假设用户（以及她选择的记录器）想要什么。它们不一定由同一个人所有。考虑走到一个任务知道详细程度并且只在诊断详细程度时记录某些信息的构建。您想在控制台上以安静的详细程度进行构建，但还要附加一个数据库记录器，该记录器绝对记录所有内容。你不能因为任务从来没有触发过事件，因为它看到了安静的冗长。
(2) 重要性和详细程度会混淆。重要性是构建过程对特定详细程度的记录器可能想要处理事件的提示。它们存在于不同的领域：在任务和构建过程中的重要性，仅在记录器中的详细程度。
(3) Verbosity 本身（例如，/verbosity）只是一个默认值。记录器通常允许您为它们指定特定的详细程度。例如 /fileloggerparameters:verbosity=detailed。任务应该得到哪个？可能有几个。
话虽如此，回想起来，有一个很好的理由重新审视这一点。这是因为在 Log 对象上触发大量事件（您可能会合理地进行诊断）会显着影响构建性能，即使在它们被记录器丢弃的较低详细程度时也是如此。为了解决这个问题，我们可能应该让构建过程至少知道它是否处于某种“超级详细”模式，在这种模式下可以安全地疯狂记录。
此外，最终重要的是完成工作。所以也许所有这些细节都过于复杂了。
丹——几年前我帮助设计了这个。