directory-build-organization
Guide for organizing MSBuild infrastructure with Directory.Build.props, Directory.Build.targets, Directory.Packages.props, and Directory.Build.rsp. USE FOR: structuring multi-project repos, centralizing build settings, implementing NuGet Central Package Management (CPM) with ManagePackageVersionsCentrally, consolidating duplicated properties across .csproj files, setting up multi-level Directory.Build hierarchy with GetPathOfFileAbove, understanding evaluation order (Directory.Build.props → SDK .props → .csproj → SDK .targets → Directory.Build.targets). Critical pitfall: $(TargetFramework) con
npx skills add dotnet/skills --skill directory-build-organization --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
# Organizing Build Infrastructure with Directory.Build Files ## Directory.Build.props vs Directory.Build.targets Understanding which file to use is critical. They differ in **when** they are imported during evaluation: **Evaluation order:** ``` Directory.Build.props → SDK .props → YourProject.csproj → SDK .targets → Directory.Build.targets ``` | Use `.props` for | Use `.targets` for | |---|---| | Setting property defaults | Custom build targets | | Common item definitions | Late-bound property overrides | | Properties projects can override | Post-build steps | | Assembly/package metadata | Conditional logic on final values | | Analyzer PackageReferences | Targets that depend on SDK-defined properties | **Rule of thumb:** Properties and items go in `.props`. Custom targets and late-bound logic go in `.targets`. Because `.props` is imported before the project file, the project can override any value set there. Because `.targets` is imported after everything, it gets the final say—but projects cannot override `.targets` values. ### ⚠️ Critical: TargetFramework Availability in .props vs .targets **Property conditions on `$(TargetFramework)` in `.props` files silently fail for single-ta
- Directory.Build.props vs Directory.Build.targets
- ⚠️ Critical: TargetFramework Availability in .props vs .targets
- Directory.Build.props
- Directory.Build.targets
- Directory.Packages.props (Central Package Management)
- Directory.Build.rsp
- Multi-level Directory.Build Files
- Artifact Output Layout (.NET 8+)
- Workflow: Organizing Build Infrastructure
- Troubleshooting
dotnet msbuild -pp:output.xml MyProject.csproj
What does the directory-build-organization skill do?
Guide for organizing MSBuild infrastructure with Directory.Build.props, Directory.Build.targets, Directory.Packages.props, and Directory.Build.rsp. USE FOR: structuring multi-project repos, centralizing build settings, implementing NuGet Central Package Management (CPM) with ManagePackageVersionsCentrally, consolidating duplicated properties across .csproj files, setting up multi-level Directory.Build hierarchy with GetPathOfFileAbove, understanding evaluation order (Directory.Build.props → SDK .props → .csproj → SDK .targets → Directory.Build.targets). Critical pitfall: $(TargetFramework) con
How do I install it?
Run `npx skills add dotnet/skills --skill directory-build-organization --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From dotnet/skills, a repository with 4,927 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.