dotnet-project-structure

Configures modern .NET solutions with .slnx files, central package management, and SDK pinning.

Updated Aug 10, 2025

Search Tags:#dotnet #nuget #slnx #global.json #msbuild #sourcelink #central package management

Ready to run

npx skills add https://github.com/afonsoft/ai-studio-workspace --skill dotnet-project-structure-afonsoft

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: dotnet-project-structure
Source: https://github.com/afonsoft/ai-studio-workspace/tree/main/agents/skills/dotnet-project-structure
Command: npx skills add https://github.com/afonsoft/ai-studio-workspace --skill dotnet-project-structure-afonsoft

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Setting up a new .NET solution involves many scattered configuration decisions—solution file format, build properties, package versions, SDK versions, and release versioning—that often become inconsistent across projects and teams. ## Core Features & Use Cases - Modern Solution Format: Migrate from legacy .sln to the XML-based .slnx format for readable, merge-friendly solution files. - Centralized Build Configuration: Use Directory.Build.props and Directory.Packages.props to enforce shared metadata, language settings, SourceLink, and central package version management. - Version Automation: Parse RELEASE_NOTES.md with PowerShell scripts to bump VersionPrefix and package release notes, integrated into CI/CD pipelines. - Use Case: When starting a new .NET 9/10 solution, apply this Skill to scaffold global.json SDK pinning, NuGet.Config, central package versions, and a build.ps1 script that keeps NuGet package versions in sync with release notes. ## Quick Start Set up a new .NET solution using the modern .slnx format with central package management and SDK version pinning.

Frequently Asked Questions about dotnet-project-structure

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

FAQPage Schema

How do I migrate a .sln file to the new .slnx format?▼

Run dotnet sln migrate in the directory containing your solution, or dotnet sln MySolution.sln migrate for a specific file. This requires .NET SDK 9.0.200 or later. After migration, delete the old .sln file to avoid conflicts with automatic solution detection.

How to set up central package management in .NET?▼

Create a Directory.Packages.props file at the solution root with ManagePackageVersionsCentrally set to true, then declare all PackageVersion entries there. Project files reference packages with PackageReference but omit the Version attribute, so all projects share one source of truth.

What .NET SDK version is required for .slnx files?▼

The .slnx format requires .NET SDK 9.0.200 or later, Visual Studio 17.13, or MSBuild from Build Tools 17.13. Starting with .NET 10, dotnet new sln creates .slnx files by default; in .NET 9 you must pass --format slnx explicitly.

Can I keep both .sln and .slnx files in the same repository?▼

No, keeping both formats causes problems with automatic solution detection and can lead to synchronization issues. After migrating to .slnx, delete the legacy .sln file so tooling consistently uses the XML-based format.

How do I pin the .NET SDK version for my team?▼

Add a global.json file at the repository root specifying the sdk version and a rollForward policy. The recommended policy is latestFeature, which allows patch updates within the same feature band while keeping builds consistent across environments.

Why should I use Directory.Build.props in a .NET solution?▼

Directory.Build.props centralizes build properties like LangVersion, Nullable, TreatWarningsAsErrors, package metadata, and SourceLink settings for every project in the tree. It eliminates duplicated configuration and lets you define reusable target framework properties referenced by all csproj files.