directory-build-organization

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

1|Updated Apr 1, 2026
One-click install
npx skills add https://github.com/AlahmadiQ8/sre-agent-demo --skill directory-build-organization-alahmadiq8
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: directory-build-organization
Source: https://github.com/AlahmadiQ8/sre-agent-demo/tree/main/.claude/skills/directory-build-organization
Command: npx skills add https://github.com/AlahmadiQ8/sre-agent-demo --skill directory-build-organization-alahmadiq8

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 (LangVersion, Nullable, TreatWarningsAsErrors, metadata) into Directory.Build.props and late-bound logic into Directory.Build.targets, with clear guidance on evaluation order. - NuGet Central Package Management: Set up Directory.Packages.props with ManagePackageVersionsCentrally, PackageVersion entries, and GlobalPackageReference for repo-wide analyzers. - Multi-Level Hierarchies & Pitfall Avoidance: Chain nested Directory.Build files with GetPathOfFileAbove and avoid the silent failure of $(TargetFramework) property conditions in .props files. - Use Case: A solution with 20 projects each repeating the same PropertyGroup and package versions is refactored into a root Directory.Build.props, Directory.Packages.props, and src/test-level overrides, leaving each .csproj with only its TargetFramework and unique references. ## Quick Start Ask the assistant to audit the .csproj files in this repository and centralize the duplicated build settings 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.

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

Directory.Build.props is imported before the project file, so it sets defaults that projects can override. Directory.Build.targets is imported after the SDK, giving it the final say and access to SDK-defined properties like OutputPath and TargetFramework.

Why is my TargetFramework condition in Directory.Build.props not working?

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 using GetPathOfFileAbove at the top of the inner file, conditioned on the parent file existing.

When should I not use Directory.Build files?

They add no value for single-project solutions with no shared settings, and they do not apply to non-MSBuild build systems. Migrating legacy projects to SDK-style format is a separate concern handled by modernization tooling.