dotnet-msbuild-diagnostics

Capture the build with dotnet build -bl:<dir>/build-{}.binlog, then run binlog_overview, binlog_diagnose, and binlog_errors in order. Route the error class using the triage table, for example MSB4019 to binlog_imports or NU1* restore errors to binlog_nuget, and fix the first error before recapturing.

Pass -bl:<dir>/<purpose>-{}.binlog on any dotnet command that runs MSBuild; MSBuild replaces {} with a UTC timestamp, process id, and random string so each invocation writes one file. Failed builds keep the log, and imports are embedded by default.

BuildCheck runs inbox build checks via dotnet build -check and reports each finding as a BC-coded diagnostic, such as BC0101 for shared output paths or BC0201 for uninitialized property reads. Configure severity and scope per code in .editorconfig under a section header.

MSB3026 typically indicates projects or project instances sharing one OutputPath or IntermediateOutputPath, causing double writes in parallel builds. Detect it with dotnet build -check (BC0101/BC0102), binlog_compare_property on IntermediateOutputPath, and binlog_double_writes.

Yes. Above 200 MB the server answers tree queries from an automatically extracted subtree and caches it for seven days; BINLOG_MCP_AUTO_EXTRACT_MB sets the threshold. For targeted investigations, use binlog_extract_preview and binlog_extract to scope the analysis to selected projects.

Capture comparable builds with -bl, then run binlog_build_graph for the critical path, binlog_expensive_projects and binlog_expensive_targets for the slowest work, and binlog_analyzer_summary on a -p:ReportAnalyzer=true capture for analyzer cost. Compare results only against captures taken under identical conditions.