dotnet-project-structure

Automate .NET project skeleton setup with .slnx, Directory.Build.props, and global.json.

Updated Mar 3, 2026
One-click install
npx skills add https://github.com/Thorstensen/claude-template --skill dotnet-project-structure-thorstensen
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dotnet-project-structure
Source: https://github.com/Thorstensen/claude-template/tree/main/.claude/skills/project-structure
Command: npx skills add https://github.com/Thorstensen/claude-template --skill dotnet-project-structure-thorstensen

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Modern .NET projects often suffer from fragmentation when teams start multiple solutions with divergent folder layouts, inconsistent build configurations, and varied versioning strategies. This Skill provides a standardized project skeleton that includes a modern .slnx-based solution format, centralized build configuration (Directory.Build.props), central package management (Directory.Packages.props), SourceLink integration for improved debugging, version management with RELEASE_NOTES.md, and SDK pinning with global.json to ensure consistent builds across environments.

Core Features & Use Cases

  • Modern solution format (.slnx) for easier diffs and readability
  • Centralized build configuration via Directory.Build.props and reusable properties
  • Central package version management via Directory.Packages.props
  • SourceLink integration to enable source debugging for NuGet packages
  • RELEASE_NOTES.md driven versioning and an automated release workflow
  • SDK pinning with global.json to guarantee reproducible builds
  • Migration guidance from older formats and best-practice adoption across teams

Quick Start

Create a new .NET solution using the .slnx format and adopt centralized build props, central package management, and SDK pinning as described.

Frequently Asked Questions about dotnet-project-structure

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

FAQPage Schema
How do I set up a .NET project structure with centralized package management and build props?

Centralized package management in .NET uses Directory.Packages.props to manage versions and Directory.Build.props to standardize build properties across all projects. This approach ensures configuration consistency across multi-project repositories and standardizes your solution layout.

What is the .slnx solution format and when should I use it for .NET projects?

The .slnx solution format is a modern .NET solution file format designed for easier readability and simpler diffs. You should use it when creating new solutions across teams to reduce fragmentation from divergent folder layouts and inconsistent build configurations.

How do I pin the .NET SDK version to guarantee reproducible builds across environments?

You pin the .NET SDK version using a global.json file to guarantee reproducible builds across environments. By specifying the required SDK version in global.json, you ensure consistent builds across all developer machines and CI pipelines.

Does central package management work with SourceLink integration in .NET multi-project repos?

Yes, central package management works with SourceLink integration in .NET multi-project repos. You can configure Directory.Packages.props alongside SourceLink to enable source debugging for NuGet packages while maintaining centralized version control.

What's the best way to manage .NET project versioning with RELEASE_NOTES.md?

The best way to manage .NET project versioning with RELEASE_NOTES.md is to drive versioning from the release notes file itself. This approach automates your release workflow and standardizes version management across multiple projects in the solution.

Can I migrate older .NET solution formats to use Directory.Build.props and central package management?

Yes, you can migrate older .NET solution formats to use Directory.Build.props and central package management. The migration process provides guidance for adopting modern practices like .slnx format, centralized build configuration, and SDK pinning across existing projects.