directory-build-organization

Organizes MSBuild infrastructure using Directory.Build.props, Directory.Build.targets, and Central Package Management.

Updated Jul 12, 2026
One-click install
npx skills add https://github.com/Patrick-Rex/DotNetTechSamples --skill directory-build-organization-patrick-rex
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: directory-build-organization
Source: https://github.com/Patrick-Rex/DotNetTechSamples/tree/main/.agents/plugins/dotnet-msbuild/skills/directory-build-organization
Command: npx skills add https://github.com/Patrick-Rex/DotNetTechSamples --skill directory-build-organization-patrick-rex

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Multi-project .NET repositories accumulate duplicated properties, package versions, and build logic across every .csproj file, making updates error-prone and inconsistent. This Skill guides the centralization of shared build settings into Directory.Build files and NuGet Central Package Management. ## Core Features & Use Cases - Centralized Build Settings: Move shared properties like Nullable, TreatWarningsAsErrors, and assembly metadata into Directory.Build.props, with correct guidance on props vs targets evaluation order. - Central Package Management (CPM): Set up Directory.Packages.props with ManagePackageVersionsCentrally, PackageVersion entries, and GlobalPackageReference for repo-wide analyzers. - Multi-Level Hierarchies: Chain nested Directory.Build.props files for src/ and test/ folders using GetPathOfFileAbove, plus Directory.Build.rsp for default CLI arguments. - Pitfall Detection: Avoid the silent failure where $(TargetFramework) conditions in .props files never match for single-targeting projects. - Use Case: A solution with 20 projects each repeating the same Nullable, LangVersion, and analyzer PackageReference settings can be refactored so each .csproj contains only its TargetFramework and unique package references. ## Quick Start Ask the assistant to audit all .csproj files in the solution and centralize the duplicated properties and package versions into Directory.Build.props and Directory.Packages.props.

Frequently Asked Questions about directory-build-organization

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I centralize NuGet package versions across multiple .NET projects?

Enable Central Package Management by creating a Directory.Packages.props file at the repo root with ManagePackageVersionsCentrally set to true. Define all versions as PackageVersion items there, then remove the Version attribute from PackageReference entries in individual .csproj files.

What is the difference between Directory.Build.props and Directory.Build.targets?

Directory.Build.props is imported before the project file, so projects can override its values; use it for property defaults and metadata. Directory.Build.targets is imported after everything, so use it for custom targets and properties depending on SDK-defined values.

Why does my TargetFramework condition in Directory.Build.props not work?

For single-targeting projects, $(TargetFramework) is empty during .props evaluation because it is set later in the project body, so property conditions silently never match. Move the conditional property to Directory.Build.targets; ItemGroup and Target conditions are unaffected.

How do I use multiple Directory.Build.props files in nested folders?

MSBuild only auto-imports the first Directory.Build.props found walking up from the project. To chain levels, add an explicit Import element using MSBuild::GetPathOfFileAbove at the top of the inner file, guarded by an Exists condition.

When should I not use Directory.Build files?

Avoid them for single-project solutions with no shared settings, since centralization adds indirection without benefit. They also do not apply to non-MSBuild build systems, and migrating legacy projects to SDK-style format is a separate task.