Consolidate `dotnet/templating` into `dotnet/sdk`

[MichaelSimons]

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

Content in dotnet/templating	Destination in dotnet/sdk
src/ (engine libraries)	src/TemplateEngine/
tools/ (dotnet-new CLI tool)	src/TemplateEngine/Tools/
test/	test/TemplateEngine/
template_feed/	template_feed/ (merged with existing)
docs/	documentation/TemplateEngine (merged with existing)
dotnet-template-samples	Preserved under documentation/TemplateEngine/Samples or linked externally
Microsoft.TemplateEngine.sln	src/TemplateEngine/Microsoft.TemplateEngine.sln
search-cache-pipeline.yml	eng/pipelines/
Assorted files (e.g. CODEOWNERS, Directory.*.props/targets, etc)	Merged into cooresponding SDK files
Assorted files (.gitattributes, LICENSE, README, auzre-pipelines*.yml)	Redundant — already exists in SDK; no action needed

---

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

[Frulfump]

Nice! There's been very little attention given to issues (and PRs?) in the templating repo, hoping this will change with clear ownership in the sdk repo.

[marcpopMSFT]

FYI @DonnaChen888 We should probably pause taking any changes into main that have code changes in them. Version flows are probably fine as they'll flow to SDK as well but any code changes will get lost as the code has already been migrated over and we're into phase 2 which is getting the build working over there.

[DonnaChen888]

FYI @DonnaChen888 We should probably pause taking any changes into main that have code changes in them. Version flows are probably fine as they'll flow to SDK as well but any code changes will get lost as the code has already been migrated over and we're into phase 2 which is getting the build working over there.

Thanks Marc, understood.

I’ll pause merging any code-change PRs into dotnet/templating (including main) during the consolidation.
Only version/config-only flows will be merged.

[MichaelSimons]

I’ll pause merging any code-change PRs into dotnet/templating (including main) during the consolidation.
Only version/config-only flows will be merged.

Just for clarity, only main PRs need to be paused. Servicing PRs should be merged.