Ever felt overwhelmed by redundant package references and bloated .csproj files when managing multiple .NET projects? If so, you're not alone—and there's a clever, developer-friendly solution waiting for you.

The Problem: Repetition When You Don't Need It

Imagine you're working on a solution structured into services, each containing the familiar trio:

• Model – your EF Core data access layer
• Domain – the core business logic
• Host – the Web API frontend

Your folder structure likely looks something like:

Root
├── Model
├── Domain
└── Host

The issue? Besides explicit project-to-project references (Domain → Model, Host → Domain), these projects often carry the same NuGet packages—like System.Text.Json—redundantly in each .csproj. Since NuGet supports transitive references, this duplication is unnecessary and makes maintenance a pain when updates roll around.

Enter Directory.Build.props: One File to Rule Them All

What if you could pull out those common properties and package references into a single, centralized file—and keep your .csproj files ultra-light?

That's exactly what Directory.Build.props lets you do. Here's the streamlined idea:

1. Create a Directory.Build.props file at the root of your solution.
2. Inside, define shared settings and packages—like target framework, nullable settings, and shared dependencies.
3. Use MSBuild conditions within ItemGroup tags to attach package references only when needed. For example:

<ItemGroup Condition="$(MSBuildProjectName.EndsWith('Model'))">
  <PackageReference Include="Microsoft.EntityFrameworkCore" Version="10.0.0-preview.5.25277.114" />
</ItemGroup>

This ensures specific dependencies (EF in this case) only load for the relevant project.

Here’s what a polished Directory.Build.props might look like:

<Project>
  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="System.Text.Json" Version="10.0.0-preview.5.25277.114" />
  </ItemGroup>

  <ItemGroup Condition="$(MSBuildProjectName.EndsWith('Model'))">
    <PackageReference Include="Microsoft.EntityFrameworkCore" Version="10.0.0-preview.5.25277.114" />
  </ItemGroup>

  <ItemGroup Condition="$(MSBuildProjectName.EndsWith('Domain'))">
    <PackageReference Include="Polly" Version="8.6.1" />
    <ProjectReference Include="..\Model\Model.csproj" />
  </ItemGroup>

  <ItemGroup Condition="$(MSBuildProjectName.EndsWith('Host'))">
    <ProjectReference Include="..\Domain\Domain.csproj" />
  </ItemGroup>
</Project>

With this in place, each project’s .csproj can be reduced to a single line:

<Project Sdk="Microsoft.NET.Sdk" />

Neat, minimalist, and entirely functional.

Why It Matters

• Centralized Updates: Want to bump the EF or System.Text.Json version? Just edit one file.
• Cleaner Repos: .csproj files are concise—no noise, just what matters.
• Scalability: Updating or cloning project templates across services becomes a breeze.

Final Thoughts

Directory.Build.props isn't just a feature—it's a productivity booster. It’s particularly helpful if you're managing dozens (or hundreds) of microservices or modular projects. With this setup, you get cleaner structure, easier updates, and better clarity.

What do you think—could your .csproj files benefit from this cleanup? I'd love to hear your strategy: drop a comment or reach out!