msbuild-modernization

Migrate legacy MSBuild project files to SDK-style format with PackageReference.

Updated Sep 22, 2026
One-click install
npx skills add https://github.com/bytecakelake/Nurse-Scheduler --skill msbuild-modernization-bytecakelake
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: msbuild-modernization
Source: https://github.com/bytecakelake/Nurse-Scheduler/tree/main/.agents/plugins/dotnet-msbuild/skills/msbuild-modernization
Command: npx skills add https://github.com/bytecakelake/Nurse-Scheduler --skill msbuild-modernization-bytecakelake

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Legacy .NET projects carry verbose XML boilerplate, explicit file lists, packages.config, and AssemblyInfo.cs files that make builds hard to maintain. This Skill guides the conversion of those projects to the concise SDK-style format used by modern .NET. ## Core Features & Use Cases - Legacy Detection: Identify legacy projects via ToolsVersion attributes, MSBuildToolsPath imports, explicit Compile includes, and .csproj files over 50 lines. - Step-by-Step Migration Checklist: Replace the project root element, map TargetFrameworkVersion to TargetFramework TFMs, remove explicit file includes, delete AssemblyInfo.cs in favor of auto-generated attributes, and convert packages.config to PackageReference. - Consolidation & Modernization: Centralize NuGet versions with Directory.Packages.props, share settings via Directory.Build.props/targets, and enable Nullable and ImplicitUsings. - Use Case: You inherit a .NET Framework 4.7.2 solution with 80-line .csproj files and packages.config. Follow the checklist to reduce each project to ~10 lines of SDK-style XML, then consolidate shared properties at the repo root. ## Quick Start Ask the AI to convert my legacy .csproj file to SDK-style format and migrate packages.config to PackageReference.

Frequently Asked Questions about msbuild-modernization

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

FAQPage Schema
How do I convert a legacy .csproj to SDK-style format?▼

Replace the root element with <Project Sdk="Microsoft.NET.Sdk">, change TargetFrameworkVersion to TargetFramework (e.g., v4.7.2 to net472), delete explicit Compile includes and AssemblyInfo.cs, and remove default configuration boilerplate. Tools like dotnet try-convert automate the first pass.

How to migrate packages.config to PackageReference?▼

Convert each packages.config entry into a <PackageReference Include="..." Version="..." /> item in the .csproj, then delete packages.config. Visual Studio offers a right-click migration option, and SDK-style projects auto-generate binding redirects.

Can SDK-style projects still target .NET Framework?▼

Yes, SDK-style projects support .NET Framework targets such as net472 and net48 via the TargetFramework property. You get the simplified format without moving to modern .NET, though some legacy tooling may not support the new format.

Should I set LangVersion to latest in my project?▼

No, avoid <LangVersion>latest</LangVersion> because the effective language version depends on the installed SDK, causing builds to vary across machines. Omit it, pin the SDK with global.json, or set an explicit numeric version like 12.

When should I not migrate a project to SDK-style?▼

Do not migrate projects already in SDK-style format, non-.NET build systems like npm or Maven, or .NET Framework projects that rely on tooling incompatible with SDK-style projects. The Skill explicitly excludes these cases.