基于我们在 .NET Core 3.0 中引入的诊断改进，我们一直在努力进一步改进这个领域。我很高兴介绍下一波诊断改进。
诊断工具不再需要 .NET SDK
直到最近，.NET 诊断工具套件还只能作为 .NET SDK 全局工具使用。虽然这为获取和更新工具提供了一种方便的方式，但这意味着在没有完整 SDK 的环境中很难获得它们。我们现在提供了一个单文件分发机制，它只需要在目标机器上提供一个运行时(3.1+)。
工具的最新版本总是可以通过以下模式的链接获得:
https://aka.ms/<tool-name>/<platform-runtime-identifier>
例如，如果你在 x64 Ubuntu 上运行 .NET Core，你可以从 https://aka.ms/dotnet-trace/linux-x64 获得 dotnet-trace。
支持的平台列表及其下载链接可以在每种工具的文档中找到，例如 dotnet-counters 文档。所有可用工具和支持的平台运行时标识符的列表可以在 diagnostics repo 中找到。
在 Windows 上分析 Linux 内存 dump
调试托管代码需要托管对象和构造的专门知识。数据访问组件（DAC）是运行时执行引擎的一个子集，它具有这些构造的知识，可以在不使用运行时的情况下访问这些托管对象。在 .NET Core 3.1.8+ 和 .NET 5+ 中，我们已经开始在 Windows 上编译 Linux DAC。在 Linux 上收集的 .NET Core 进程 dump 现在可以在 Windows 上使用 WinDBG、dotnet dump analyze 和 Visual Studio 2019 16.8 进行分析。
有关如何收集 .NET 内存 dump 以及如何分析它们的详细信息，请访问 VisualStudio 博客。
启动跟踪
.NET 诊断工具套件的工作方式是连接到运行时间创建的诊断端口，然后请求运行时使用该通道上的诊断 IPC 协议将信息导出。在 .NET Core 3.1 中，无法执行启动跟踪（通过 EventPipe；ETW 仍然是可能的），因为在工具连接到运行时之前发出的事件将会丢失。在 .NET 5 中，现在可以配置运行时在启动期间挂起自己，直到工具连接（或让运行时连接到工具）。
dotnet -counters 和 dotnet-trace 的5.0版本现在可以启动 dotnet 进程并从进程开始收集诊断信息。例如，下面的命令将启动 mydotnetapp.exe 并开始监听计数器。
dotnet counters monitor -- mydotnetapp.exe
关于启动跟踪的更多信息可以在 dotnet-counters 和 dotnet-trace 的文档页面上找到。
程序集加载诊断
在 .NET 5 中，运行时现在通过 EventPipe 为程序集绑定发出事件。此信息可以帮助您诊断运行时不能在运行时定位程序集的原因。这是对 .NET 框架中 Fusion Log Viewer（fuslogvw.exe）的替换。
可以使用以下命令收集程序集加载诊断:
dotnet-trace collect --providers Microsoft-Windows-DotNETRuntime:4:4 --process-id [process ID]
可以使用 PerfView 分析生成的 .nettrace 文件。
结束
感谢您试用 .NET 5 中更新的诊断工具。请继续给我们反馈，无论是在评论中还是在 GitHub 上。我们正在认真倾听，并将根据您的反馈继续做出改变。我们将在后续的博客文章中介绍 .NET 5 中关于诊断工具的更多改进。
原文链接
https://devblogs.microsoft.com/dotnet/diagnostics-improvements-in-net-5/
