dotnet-build-optimization

Name: dotnet-build-optimization
Author: wshaddix

65stars10forks

How to install dotnet-build-optimization?

wshaddix/dotnet-skills/dotnet-build-optimization

$npx -y skills add wshaddix/dotnet-skills --skill dotnet-build-optimization

Installs into the current project.

Summary

Diagnosing slow builds or incremental failures. Binary logs, parallel builds, restore.

Files · 1

View on GitHub

SKILL.md

1	# dotnet-build-optimization
2
3	Guidance for diagnosing and fixing build performance problems: incremental build failure diagnosis workflows, binary log analysis with MSBuild Structured Log Viewer, parallel build configuration, build caching, and restore optimization. Covers the diagnostic workflow from symptom (full rebuild on every build) through root cause (missing Inputs/Outputs, timestamp corruption, generator side effects) to fix.
4
5	Version assumptions: .NET 8.0+ SDK (MSBuild 17.8+). All examples use SDK-style projects.
6
7	Scope boundary: This skill owns build optimization and diagnostics -- incremental build failures, binary logs, parallel builds, build caching, and restore optimization. MSBuild error interpretation and CI drift diagnosis is owned by [skill:dotnet-build-analysis]. MSBuild authoring (targets, props, items, conditions) is owned by [skill:dotnet-msbuild-authoring]. Custom task development is owned by [skill:dotnet-msbuild-tasks]. NuGet lock files and Central Package Management configuration is owned by [skill:dotnet-project-structure].
8
9	Cross-references: [skill:dotnet-msbuild-authoring] for custom targets, import ordering, and incremental build authoring patterns. [skill:dotnet-msbuild-tasks] for custom task development. [skill:dotnet-build-analysis] for interpreting MSBuild errors, NuGet restore failures, and CI drift diagnosis. [skill:dotnet-project-structure] for lock files, CPM, and nuget.config configuration.
10
11	---
12
13	## Incremental Build Failure Diagnosis
14
15	When a target runs on every build despite no source changes, the build is not incremental. This wastes time and masks real changes. The diagnosis workflow follows a repeatable pattern: detect the symptom, capture a binary log, identify the offending target, determine why incrementality failed, and apply the fix.
16
17	### Diagnosis Workflow
18
19	```
20	1. Symptom: Build takes longer than expected, or output says
21	"Building target 'X' completely" on every build
22	2. Capture binary log: dotnet build /bl
23	3. Open the .binlog in MSBuild Structured Log Viewer
24	4. Search for targets that ran (not skipped)
25	5. Check: Does the target have Inputs/Outputs?
26	- No -> Add Inputs/Outputs (see fix patterns below)
27	- Yes -> Compare timestamps: are outputs older than inputs?
28	-> Check for volatile writers or missing output files
29	6. Apply fix, rebuild, verify target is skipped
30	```
31
32	### Step 1: Capture a Binary Log
33
34	```bash
35	# Produce msbuild.binlog in the project directory
36	dotnet build /bl
37
38	# Named log file
39	dotnet build /bl:build-debug.binlog
40
41	# Binary log for restore + build (captures full pipeline)
42	dotnet build /bl -restore
43	```
44
45	The `/bl` switch records every MSBuild event -- property evaluations, item lists, target entry/exit, task execution, and timestamps -- into a compact binary format. Binary logs contain full source paths and environment variables; do not commit them to version control or share publicly.
46
47	### Step 2: Open in MSBuild Structured Log Viewer
48
49	Download from [msbuildlog.com](https://msbuildlog.com/). Open the `.binlog` file. Key views:
50
51	\| View \| Use \|
52	\|---\|---\|
53	\| Timeline \| See which targets ran in parallel and how long each took \|
54	\| Target Results \| Filter by "Built" (ran) vs "Skipped" (incremental hit) \|
55	\| Search \| Find specific target names, property values, or file paths \|
56	\| Properties \| Inspect evaluated property values at any point in the build \|
57	\| Items \| Inspect item collections (Compile, Content, etc.) with metadata \|
58
59	### Step 3: Find the Non-Incremental Target
60
61	In the Structured Log Viewer, search for the target name and check its result. A target that should be incremental but ran fully will show "Building target 'X' completely" with a reason:
62
63	- "Output file does not exist" -- an expected output file is missing or was deleted
64	- "Input file is newer than output file" -- a source file changed, or a preceding step rewrote an output
65	- No Inputs/Outputs declared -- the target always runs because MSBuild has no way to check freshness
66
67	---
68
69	## Common Incremental Build Failure Patterns
70
71	### Missing Inputs/Outputs on Custom Targets
72
73	Symptom: Custom target runs on every build.
74
75	Root cause: The target has no `Inputs`/`Outputs` attributes. Without them, MSBuild runs the target unconditionally.
76
77	Fix: Add `Inputs` and `Outputs` that reflect the actual files read and written:
78
79	```xml
80	<!-- BEFORE: runs every build -->
81	<Target Name="GenerateVersionFile" BeforeTargets="CoreCompile">
82	<WriteLinesToFile File="$(IntermediateOutputPath)Version.g.cs"
83	Lines="[assembly: System.Reflection.AssemblyInformationalVersion("$(Version)")]"
84	Overwrite="true" />
85	</Target>
86
87	<!-- AFTER: only runs when Version property changes (via project file edit) -->
88	<Target Name="GenerateVersionFile"
89	BeforeTargets="CoreCompi

People who liked this also viewed

6 picks

Type

lark-openapi-explorer飞书/Lark 原生 OpenAPI 探索：从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足，需要查找并调用原生飞书 OpenAPI 时使用。SkillsJul 2026378k16k
lark-skill-maker创建 lark-cli 的自定义 Skill。当用户需要把飞书 API 操作封装成可复用的 Skill（包装原子 API 或编排多步流程）时使用。SkillsJul 2026377k16k
azure-cost-optimizationOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026209k1.3k
vercel-react-native-skillsVercel's official collection of agent skillsSkillsJul 2026172k29k
mcp-builderGuide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate externaSkillsJul 202693k163k
gws-sharedgws CLI: Shared patterns for authentication, global flags, and output formatting.SkillsJul 202653k30k

dotnet-build-optimization

65stars10forks

View on GitHub

How to install dotnet-build-optimization?

wshaddix/dotnet-skills/dotnet-build-optimization

$npx -y skills add wshaddix/dotnet-skills --skill dotnet-build-optimization

Installs into the current project.

Summary

Diagnosing slow builds or incremental failures. Binary logs, parallel builds, restore.

Files · 1

View on GitHub

SKILL.md

1	# dotnet-build-optimization
2
3	Guidance for diagnosing and fixing build performance problems: incremental build failure diagnosis workflows, binary log analysis with MSBuild Structured Log Viewer, parallel build configuration, build caching, and restore optimization. Covers the diagnostic workflow from symptom (full rebuild on every build) through root cause (missing Inputs/Outputs, timestamp corruption, generator side effects) to fix.
4
5	Version assumptions: .NET 8.0+ SDK (MSBuild 17.8+). All examples use SDK-style projects.
6
7	Scope boundary: This skill owns build optimization and diagnostics -- incremental build failures, binary logs, parallel builds, build caching, and restore optimization. MSBuild error interpretation and CI drift diagnosis is owned by [skill:dotnet-build-analysis]. MSBuild authoring (targets, props, items, conditions) is owned by [skill:dotnet-msbuild-authoring]. Custom task development is owned by [skill:dotnet-msbuild-tasks]. NuGet lock files and Central Package Management configuration is owned by [skill:dotnet-project-structure].
8
9	Cross-references: [skill:dotnet-msbuild-authoring] for custom targets, import ordering, and incremental build authoring patterns. [skill:dotnet-msbuild-tasks] for custom task development. [skill:dotnet-build-analysis] for interpreting MSBuild errors, NuGet restore failures, and CI drift diagnosis. [skill:dotnet-project-structure] for lock files, CPM, and nuget.config configuration.
10
11	---
12
13	## Incremental Build Failure Diagnosis
14
15	When a target runs on every build despite no source changes, the build is not incremental. This wastes time and masks real changes. The diagnosis workflow follows a repeatable pattern: detect the symptom, capture a binary log, identify the offending target, determine why incrementality failed, and apply the fix.
16
17	### Diagnosis Workflow
18
19	```
20	1. Symptom: Build takes longer than expected, or output says
21	"Building target 'X' completely" on every build
22	2. Capture binary log: dotnet build /bl
23	3. Open the .binlog in MSBuild Structured Log Viewer
24	4. Search for targets that ran (not skipped)
25	5. Check: Does the target have Inputs/Outputs?
26	- No -> Add Inputs/Outputs (see fix patterns below)
27	- Yes -> Compare timestamps: are outputs older than inputs?
28	-> Check for volatile writers or missing output files
29	6. Apply fix, rebuild, verify target is skipped
30	```
31
32	### Step 1: Capture a Binary Log
33
34	```bash
35	# Produce msbuild.binlog in the project directory
36	dotnet build /bl
37
38	# Named log file
39	dotnet build /bl:build-debug.binlog
40
41	# Binary log for restore + build (captures full pipeline)
42	dotnet build /bl -restore
43	```
44
45	The `/bl` switch records every MSBuild event -- property evaluations, item lists, target entry/exit, task execution, and timestamps -- into a compact binary format. Binary logs contain full source paths and environment variables; do not commit them to version control or share publicly.
46
47	### Step 2: Open in MSBuild Structured Log Viewer
48
49	Download from [msbuildlog.com](https://msbuildlog.com/). Open the `.binlog` file. Key views:
50
51	\| View \| Use \|
52	\|---\|---\|
53	\| Timeline \| See which targets ran in parallel and how long each took \|
54	\| Target Results \| Filter by "Built" (ran) vs "Skipped" (incremental hit) \|
55	\| Search \| Find specific target names, property values, or file paths \|
56	\| Properties \| Inspect evaluated property values at any point in the build \|
57	\| Items \| Inspect item collections (Compile, Content, etc.) with metadata \|
58
59	### Step 3: Find the Non-Incremental Target
60
61	In the Structured Log Viewer, search for the target name and check its result. A target that should be incremental but ran fully will show "Building target 'X' completely" with a reason:
62
63	- "Output file does not exist" -- an expected output file is missing or was deleted
64	- "Input file is newer than output file" -- a source file changed, or a preceding step rewrote an output
65	- No Inputs/Outputs declared -- the target always runs because MSBuild has no way to check freshness
66
67	---
68
69	## Common Incremental Build Failure Patterns
70
71	### Missing Inputs/Outputs on Custom Targets
72
73	Symptom: Custom target runs on every build.
74
75	Root cause: The target has no `Inputs`/`Outputs` attributes. Without them, MSBuild runs the target unconditionally.
76
77	Fix: Add `Inputs` and `Outputs` that reflect the actual files read and written:
78
79	```xml
80	<!-- BEFORE: runs every build -->
81	<Target Name="GenerateVersionFile" BeforeTargets="CoreCompile">
82	<WriteLinesToFile File="$(IntermediateOutputPath)Version.g.cs"
83	Lines="[assembly: System.Reflection.AssemblyInformationalVersion("$(Version)")]"
84	Overwrite="true" />
85	</Target>
86
87	<!-- AFTER: only runs when Version property changes (via project file edit) -->
88	<Target Name="GenerateVersionFile"
89	BeforeTargets="CoreCompi

People who liked this also viewed

6 picks

Type