# Sdk Style Conversion

> Converts legacy .NET projects to SDK-style project format. Use when user wants to convert to SDK-style, modernize project files, or migrate from legacy csproj format. Does not change target frameworks.

- Skill: `microsoft/sdk-style-conversion` (Agent Skill)
- Install (CLI): `npx skillmds@latest add microsoft/sdk-style-conversion`
- Raw SKILL.md: https://api.skillmd.com/api/skills/microsoft/sdk-style-conversion/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Microsoft (https://skillmd.com/u/microsoft)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/microsoft/sdk-style-conversion

---


# SDK-style Project Conversion

## 1. Assessment

Scan the solution to identify which projects need conversion and what complications to expect. Capture findings in `assessment.md`.

### How to Identify Non-SDK-Style Projects

A project is non-SDK-style if it has any of:
- No `Sdk` attribute on the `<Project>` element
- Explicit file includes (`<Compile Include="...">` for every source file)
- `packages.config` file in the project directory
- `<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />` or similar explicit tool imports

### Patterns to Identify

For each non-SDK-style project, record:

| Pattern | What to Record |
|---------|---------------|
| `packages.config` | Present? — must be migrated to `PackageReference` |
| Explicit file includes (`Compile`, `Content`, `None`, `EmbeddedResource`) | Count — SDK-style uses globbing, these become implicit |
| Custom `Import` elements | Which targets are imported — may need preservation |
| `AssemblyInfo.cs` with assembly attributes | SDK-style auto-generates these — potential duplication |
| Multi-targeting (`TargetFrameworks` plural) | Already SDK-like, may be partial conversion |
| WPF/WinForms markers (`<UseWPF>`, `<UseWindowsForms>`, XAML files) | Needs `Microsoft.NET.Sdk.WindowsDesktop` or `net*-windows` TFM handling |
| Web project type GUIDs (`{349c5851-...}`) | ASP.NET projects have special post-conversion considerations |
| Custom build events or targets | Must be preserved through conversion |

### Risk Indicators

Flag these as higher complexity:
- **ASP.NET Framework web projects**: SDK-style conversion is technically possible, but .NET tooling (Visual Studio, `dotnet build`) does not fully support SDK-style projects targeting ASP.NET Framework (non-Core). Custom MSBuild techniques or workarounds may be needed to maintain build and publish behavior. NuGet compatibility issues can also arise post-conversion
- **Heavy custom MSBuild logic**: Custom targets, conditional imports, or property manipulation that might conflict with SDK defaults
- **Shared projects or linked files**: File linking patterns change in SDK-style

### Assessment Output

Create `assessment.md` in the workflow folder with this structure:

```markdown
# Assessment: SDK-style Conversion

## Projects to Convert
| Project | Path | packages.config | Custom Imports | Special Type | Risk |
|---------|------|----------------|----------------|-------------|------|
| MyApp.Core | src/Core/MyApp.Core.csproj | Yes | None | Class library | Low |
| MyApp.Web | src/Web/MyApp.Web.csproj | Yes | 2 custom targets | ASP.NET | High |

## Already SDK-style (no action needed)
- [list or "none"]

## Baseline
- Solution builds: Yes/No
- Warning count: [number]

## Key Findings
- [Notable patterns, risks, or decisions needed]
```

## 2. Planning

Based on the assessment, create `plan.md` with tasks ordered topologically (leaf dependencies first, so each project can build after conversion).

For each task include:
- Which projects or groups of projects are covered
- What complications are expected (packages.config, custom imports, special project types)
- Risk level and anything requiring user decision

**Hard constraint**: Do not change TargetFramework during conversion — that is a separate scenario (dotnet-version-upgrade).

## 3. Execution

Execute the plan task by task. For any task that involves converting a project to SDK-style, apply the **converting-to-sdk-style** feature skill. It provides a dedicated conversion tool and a two-phase workflow (planning + execution with per-project checklist).

Verify the solution builds after each project or group is converted — catching errors early prevents cascading failures in dependent projects.

## 4. Validation

- Build the full solution — zero errors required (or no regressions from baseline)
- All `packages.config` files removed from converted projects
- No TargetFramework values changed
- If the project had tests, run them and report results