Consolidate dotnet/templating into dotnet/sdk

Overview

This issue tracks the work to consolidate the dotnet/templating repository into dotnet/sdk, following the pattern established by the dotnet/installer consolidation.

Motivation

Maintaining the Templating Engine/tools in a separate repository carries overhead. A separate repo means a separate set of code flows, independent 1ES compliance requirements, and duplicated engineering infrastructure — all for a relatively small codebase. Consolidation eliminates that overhead and reduces the ongoing maintenance cost for the SDK team.

It also speeds up development. Today, changes in dotnet/templating must flow through the VMR and back down to dotnet/sdk before they can be validated end-to-end, which has been a recurring source of friction and delay. With the source in-tree, that round-trip disappears.

Developer workflow

There are valid concerns about the developer experience for contributors who work primarily in the Template Engine space. These can be mitigated:

• Solution filters — A .slnf scoped to the Template Engine projects lets contributors load, build, and debug just the templating code without pulling in the full SDK.
• Faster inner-loop builds — Ongoing work to improve SDK build times benefits all contributors, including those focused on templating.
• Targeted CI validation — We can invest in scoping CI to the affected area when changes are limited to a specific part of the SDK, reducing feedback time for focused PRs.

These improvements make all contributors more productive in the SDK repo, and that is the direction we would like to head.

Where content lands in dotnet/sdk

Phases

Phase 1 — Source migration (history-preserving file copy)

Copy source straight across ensuring commit history is preserved. No build hookup yet; the projects will exist in the tree but won't be wired into the SDK's build.

Phase 2 — Build & test hookup

Wire the migrated source, tools, and tests into the SDK build and CI:

• Remove dotnet/templating entries from Version.Details.*
• Convert NuGet package references between engine and tool projects to project references
• Add projects to the relevant solution(s) and Directory.Build.props / Directory.Packages.props as needed
• Enable migrated tests in SDK CI (Helix integration, UnitTests.proj)
• Validate full build & test pass

Phase 3 — Cleanup & integration

Address lingering integration items that don't block building/testing but should be resolved before the repo is fully canonical:

• Merge CODEOWNERS entries into the SDK CODEOWNERS
• Review and reconcile .editorconfig, Directory.Build.props overrides, global analyzer suppressions, etc.
• Stand-up search-cache-pipeline

Phase 4 — VMR and downstream version updates

Once the above phases are merged and the SDK is the canonical source:

• Remove dotnet/templating from the VMR (Virtual Monolithic Repository) source manifest
• Update Version.Details.xml / global.json in consuming repos (ASP.NET Core, Windows Forms, etc.) to pull Microsoft.TemplateEngine.* packages from the SDK instead of from dotnet/templating
• Validate that all downstream repos build successfully against the SDK-vended packages

Phase 5 — Archive dotnet/templating

Following the pattern used for dotnet/installer:

• Create a archive branch in dotnet/templating which mimics the dotnet/installer repo.
• Update the repo README to indicate the repo is deprecated and point to dotnet/sdk

Tracking

• Phase 1 — Source migration
• Phase 2 — Build & test hookup
• Phase 3 — Cleanup & integration
• Phase 4 — VMR & downstream version updates
• Phase 5 — Archive dotnet/templating
• Phase 6 — Migrate search cache pipeline