directory-build-organization

Centralizes MSBuild properties, targets, and NuGet package versions in .NET repositories via Directory.Build.props/targets/packages.props files.

1|Updated May 21, 2026
One-click install
npx skills add https://github.com/1k-off/umbraco-observability-playground --skill directory-build-organization-1k-off
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: directory-build-organization
Source: https://github.com/1k-off/umbraco-observability-playground/tree/main/.agents/skills/directory-build-organization
Command: npx skills add https://github.com/1k-off/umbraco-observability-playground --skill directory-build-organization-1k-off

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

It solves inconsistent and duplicated MSBuild settings across many .csproj files by providing a clear, correct way to centralize properties, items, build logic, and NuGet package versions.

Core Features & Use Cases

  • Use the right file for the right job: apply defaults and item definitions in Directory.Build.props, and late-bound or conditional logic in Directory.Build.targets.
  • Enable NuGet Central Package Management (CPM): manage package versions once via Directory.Packages.props and remove Version= duplication from individual projects.
  • Support multi-level repo hierarchies: chain directory build files with GetPathOfFileAbove so src/, test/, and other folders can safely inherit and override repo-wide settings.
  • Avoid a common MSBuild pitfall: prevents incorrect use of $(TargetFramework) conditions in .props files for single-target projects (moving such logic to .targets).
  • Operational use: standardize compilation settings, analyzers, artifact output layout, and validation checks across a multi-project .NET repository.

Quick Start

Ask an AI to propose a repo-wide Directory.Build.props, Directory.Build.targets, and Directory.Packages.props plan for your solution, including what to centralize, what to keep per-project, and where to place any $(TargetFramework)-conditioned properties.

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 MSBuild settings across multiple .NET projects?

You can centralize MSBuild settings by using Directory.Build.props for default properties and Directory.Build.targets for late-bound logic, ensuring consistent compilation and artifact output layout across all projects in a multi-project .NET repository.

What is NuGet Central Package Management and how does Directory.Packages.props work?

NuGet Central Package Management (CPM) uses Directory.Packages.props to manage package versions once at the repo level, removing the need to duplicate Version= attributes in individual .csproj files and ensuring deterministic versioning across all projects.

Why are my $(TargetFramework) conditions failing in Directory.Build.props?

Conditions on $(TargetFramework) fail in Directory.Build.props because the property is not yet evaluated, so you must move such conditional logic to Directory.Build.targets to prevent silent mismatches in single-targeting projects.

Can I use Directory.Build.props to support multi-level folder hierarchies?

Yes, you can chain Directory.Build.props files across multi-level repo hierarchies using GetPathOfFileAbove, allowing src/, test/, and other folders to safely inherit and override repo-wide MSBuild settings.

What is the best way to organize NuGet package versions in a large .NET solution?

The best way to organize NuGet package versions is enabling Central Package Management with Directory.Packages.props, which standardizes version control across the repository and eliminates duplication across individual project files.

When should I use Directory.Build.props vs Directory.Build.targets?

Use Directory.Build.props for early defaults and item definitions, and Directory.Build.targets for late-bound or conditional logic like $(TargetFramework) checks, preventing evaluation-order issues and silent build mismatches.