directory-build-organization

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

Updated Jul 20, 2026
One-click install
npx skills add https://github.com/Netcodr81/kinetic-reports --skill directory-build-organization-netcodr81
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: directory-build-organization
Source: https://github.com/Netcodr81/kinetic-reports/tree/main/.github/skills/directory-build-organization
Command: npx skills add https://github.com/Netcodr81/kinetic-reports --skill directory-build-organization-netcodr81

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 so each project file contains only what is unique to it. ## Core Features & Use Cases - Centralized Build Settings: Move shared properties like Nullable, TreatWarningsAsErrors, and assembly metadata into Directory.Build.props, with custom targets and late-bound logic in Directory.Build.targets. - Central Package Management: 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 imports. - Pitfall Diagnosis: Avoid the silent failure where $(TargetFramework) property conditions in .props files never match for single-targeting projects. - Use Case: A team with 20 .csproj files repeating the same Nullable, Company, and analyzer PackageReference settings consolidates them into three root-level files, then validates with dotnet msbuild -pp to confirm the merged evaluation. ## Quick Start Ask the AI to audit all .csproj files in the repository 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 .csproj files?▼

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 each .csproj file.

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

Directory.Build.props is imported before the project file, so it sets default properties and items that projects can override. Directory.Build.targets is imported after the SDK, making it the right place for custom targets and properties depending on SDK-defined values like OutputPath.

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.

Can I use multiple Directory.Build.props files in one repository?▼

MSBuild only auto-imports the first Directory.Build.props found walking up from the project directory. To chain levels, add an explicit Import using GetPathOfFileAbove at the top of the inner file, commonly for separate src/ and test/ settings.

How do I diagnose why a Directory.Build.props setting is ignored?▼

Run dotnet msbuild -pp:output.xml on the project to produce the preprocessed file with all imports expanded inline. This shows exactly where each property is set and its final evaluated value, revealing overrides or evaluation-order issues.