From a1b35693cb5c38301061a6a2ca633aac01d8e193 Mon Sep 17 00:00:00 2001 From: Matt Thalman Date: Tue, 14 Jul 2026 10:50:50 -0500 Subject: [PATCH 1/4] Document multi-repo ownership boundaries Clarify component ownership, VMR code flow, dependency provenance, and cross-repository fix placement for SDK agents. Correct the Template Engine guidance now that its source is maintained in the SDK repository. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 99b4cd14-14dc-459c-bac7-f984c9d2632b --- .github/copilot-instructions.md | 60 ++++++++++++++++++++++++++++++--- 1 file changed, 56 insertions(+), 4 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index a8e4a3c90527..9d96c941568e 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -23,9 +23,61 @@ For a high-level project description, build status, and contribution flow, see t SDKs, container publishing, file/format/watch tools, API compatibility tooling, and workload management. -This repo does **not** own the .NET runtime, the C#/F#/VB compilers, MSBuild itself, NuGet, -or the Visual Studio project system — those are separate repositories that flow in as -dependencies. The full product (`dotnet/dotnet` VMR) composes this repo with those. +### Repository boundaries and the VMR + +An SDK command or build can expose behavior implemented by another .NET repository. Find +the component that defines the behavior before making a change; do not add an SDK +workaround merely because the symptom appears through `dotnet`. + +| Repository | Ownership boundary | +| --- | --- | +| [`dotnet/sdk`](https://github.com/dotnet/sdk) | The managed `dotnet` CLI commands and their UX/orchestration; SDK MSBuild tasks, targets, and resolvers; the Template Engine libraries and tools under `src/TemplateEngine`; the `dotnet new` host under `src/Cli/Microsoft.TemplateEngine.Cli`; and common template content under `template_feed`. | +| [`dotnet/runtime`](https://github.com/dotnet/runtime) | CLR and Mono, the base class libraries, the native `dotnet` host/muxer and apphost, runtime and reference packs, and runtime-owned deployment tooling such as NativeAOT and ILLink. SDK publish targets integrate with these artifacts but do not own their implementation. | +| [`dotnet/roslyn`](https://github.com/dotnet/roslyn) | The C# and Visual Basic compilers, compiler server, compiler APIs, and compiler behavior such as language diagnostics and code generation. The SDK supplies inputs and ships Roslyn artifacts; SDK-generated defaults and command wiring remain SDK-owned. The F# compiler is in [`dotnet/fsharp`](https://github.com/dotnet/fsharp). | +| [`dotnet/msbuild`](https://github.com/dotnet/msbuild) | The MSBuild engine, evaluation and execution semantics, logging, and core tasks and targets. SDK-specific `Microsoft.NET.*` tasks and targets remain in this repo. | +| [`NuGet/NuGet.Client`](https://github.com/NuGet/NuGet.Client) | NuGet restore, package resolution, protocols, and related MSBuild tasks. SDK CLI wrappers and SDK-specific integration remain in this repo. | +| [`dotnet/project-system`](https://github.com/dotnet/project-system) | Visual Studio-specific project-system behavior. | +| [`dotnet/templating`](https://github.com/dotnet/templating) | Historical home of the Template Engine. Its source and development moved into `dotnet/sdk` in 2026; make current Template Engine changes in this repo. See the [Template Engine overview](../documentation/TemplateEngine/README.md). | +| [`dotnet/dotnet`](https://github.com/dotnet/dotnet) | The Virtual Monolithic Repository (VMR): a synchronized mirror of product repositories plus the infrastructure for building and servicing the integrated .NET product. Product source is mirrored under `src/`; normal component development still belongs in the owning product repository. | + +Do not infer ownership from a diagnostic ID or generated code alone. Compiler diagnostics +and compiler-emitted code belong to Roslyn, but analyzers and source generators belong to +the repository that implements them, such as `dotnet/runtime` for runtime-library +generators or `dotnet/sdk` for SDK analyzers. + +The standalone SDK build consumes most sibling components as packages or other build +artifacts. Use these files to identify the exact implementation being consumed: + +- `eng/Version.Details.xml` records flowed dependency versions and source URI/commit. + Unified Build backflow commonly records `dotnet/dotnet` as the source for packages from + several product repositories; that does not transfer ownership to the VMR. When exact + source matters, inspect the corresponding `src/` directory at the recorded VMR + commit, for example `src/runtime`, `src/roslyn`, or `src/msbuild`. +- `Directory.Packages.props` maps package IDs to version properties, while + `eng/Versions.props` contains manually maintained and compatibility-specific version + policy. Trace the package or assembly back to its product repository instead of + changing a version or copying upstream code as a substitute for fixing the owner. + +The VMR synchronizes product source in both directions through +[code flow](https://github.com/dotnet/dotnet/blob/main/docs/Codeflow-PRs.md): forward flow +moves product-repository changes into the VMR, and backflow returns VMR source changes and +newly built dependencies to product repositories. Do not edit a mirrored VMR `src/*` +directory for an ordinary component fix. Direct VMR changes are for VMR infrastructure, +integration, servicing, or explicitly coordinated cross-repository work; follow the +[VMR contribution guidance](https://github.com/dotnet/dotnet#contribution). +Source-build is a validation mode, not an ownership boundary: component-specific +source-build behavior belongs with that component, while whole-product source-build +orchestration belongs in the VMR. + +For a cross-repository issue: + +1. Identify the executable, assembly, task, target, or package that implements the + behavior, and inspect the version actually consumed by this checkout. +2. Put the semantic fix and its primary tests in the owning repository. Keep only genuine + SDK orchestration, defaults, compatibility, or integration changes in `dotnet/sdk`. +3. If multiple components must change, keep each change and its tests with its owner, then + consume the flowed build. Validate the integrated VMR when the issue depends on an + exact component combination, source-build, or cross-repository target hooks. ### Architecture and major components @@ -46,7 +98,7 @@ Major source areas under `src/`: | `Containers/` | `dotnet publish` container image support. | | `Dotnet.Watch/`, `Dotnet.Format/` | `dotnet watch` and `dotnet format` tools. | | `Compatibility/` | ApiCompat / GenAPI / package validation tooling. | -| `TemplateEngine/` | CLI glue for the templating engine (engine itself is in `dotnet/templating`). | +| `TemplateEngine/` | Template Engine libraries and authoring tools. The `dotnet new` CLI host is under `Cli/Microsoft.TemplateEngine.Cli`. | | `Workloads/`, `Microsoft.DotNet.TemplateLocator/` | Workload manifests/installation, and locating workload-provided template packs. | | `Layout/` | Composes the final redist `dotnet` layout. | From 3f840ec9b99b99755e6d5b6149d737140e02d6d6 Mon Sep 17 00:00:00 2001 From: Matt Thalman Date: Thu, 16 Jul 2026 10:18:52 -0500 Subject: [PATCH 2/4] Refine multi-repo ownership guidance Qualify compiler ownership, document flowed version properties, and align direct VMR change guidance with current contribution boundaries. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 99b4cd14-14dc-459c-bac7-f984c9d2632b --- .github/copilot-instructions.md | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 6d3b7ed1fa2f..6094115d725d 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -33,17 +33,17 @@ workaround merely because the symptom appears through `dotnet`. | --- | --- | | [`dotnet/sdk`](https://github.com/dotnet/sdk) | The managed `dotnet` CLI commands and their UX/orchestration; SDK MSBuild tasks, targets, and resolvers; the Template Engine libraries and tools under `src/TemplateEngine`; the `dotnet new` host under `src/Cli/Microsoft.TemplateEngine.Cli`; and common template content under `template_feed`. | | [`dotnet/runtime`](https://github.com/dotnet/runtime) | CLR and Mono, the base class libraries, the native `dotnet` host/muxer and apphost, runtime and reference packs, and runtime-owned deployment tooling such as NativeAOT and ILLink. SDK publish targets integrate with these artifacts but do not own their implementation. | -| [`dotnet/roslyn`](https://github.com/dotnet/roslyn) | The C# and Visual Basic compilers, compiler server, compiler APIs, and compiler behavior such as language diagnostics and code generation. The SDK supplies inputs and ships Roslyn artifacts; SDK-generated defaults and command wiring remain SDK-owned. The F# compiler is in [`dotnet/fsharp`](https://github.com/dotnet/fsharp). | +| [`dotnet/roslyn`](https://github.com/dotnet/roslyn) | The C# and Visual Basic compilers, compiler server, compiler APIs, and C#/VB compiler behavior such as language diagnostics and code generation. The SDK supplies inputs and ships Roslyn artifacts; SDK-generated defaults and command wiring remain SDK-owned. The F# compiler is in [`dotnet/fsharp`](https://github.com/dotnet/fsharp). | | [`dotnet/msbuild`](https://github.com/dotnet/msbuild) | The MSBuild engine, evaluation and execution semantics, logging, and core tasks and targets. SDK-specific `Microsoft.NET.*` tasks and targets remain in this repo. | | [`NuGet/NuGet.Client`](https://github.com/NuGet/NuGet.Client) | NuGet restore, package resolution, protocols, and related MSBuild tasks. SDK CLI wrappers and SDK-specific integration remain in this repo. | | [`dotnet/project-system`](https://github.com/dotnet/project-system) | Visual Studio-specific project-system behavior. | | [`dotnet/templating`](https://github.com/dotnet/templating) | Historical home of the Template Engine. Its source and development moved into `dotnet/sdk` in 2026; make current Template Engine changes in this repo. See the [Template Engine overview](../documentation/TemplateEngine/README.md). | | [`dotnet/dotnet`](https://github.com/dotnet/dotnet) | The Virtual Monolithic Repository (VMR): a synchronized mirror of product repositories plus the infrastructure for building and servicing the integrated .NET product. Product source is mirrored under `src/`; normal component development still belongs in the owning product repository. | -Do not infer ownership from a diagnostic ID or generated code alone. Compiler diagnostics -and compiler-emitted code belong to Roslyn, but analyzers and source generators belong to -the repository that implements them, such as `dotnet/runtime` for runtime-library -generators or `dotnet/sdk` for SDK analyzers. +Do not infer ownership from a diagnostic ID or generated code alone. C# and Visual Basic +compiler diagnostics and compiler-emitted code belong to Roslyn, but analyzers and source +generators belong to the repository that implements them, such as `dotnet/runtime` for +runtime-library generators or `dotnet/sdk` for SDK analyzers. The standalone SDK build consumes most sibling components as packages or other build artifacts. Use these files to identify the exact implementation being consumed: @@ -51,19 +51,23 @@ artifacts. Use these files to identify the exact implementation being consumed: - `eng/Version.Details.xml` records flowed dependency versions and source URI/commit. Unified Build backflow commonly records `dotnet/dotnet` as the source for packages from several product repositories; that does not transfer ownership to the VMR. When exact - source matters, inspect the corresponding `src/` directory at the recorded VMR - commit, for example `src/runtime`, `src/roslyn`, or `src/msbuild`. -- `Directory.Packages.props` maps package IDs to version properties, while - `eng/Versions.props` contains manually maintained and compatibility-specific version - policy. Trace the package or assembly back to its product repository instead of - changing a version or copying upstream code as a substitute for fixing the owner. + source matters, inspect `src/source-manifest.json` and the corresponding `src/` + directory at the recorded VMR commit, for example `src/runtime`, `src/roslyn`, or + `src/msbuild`. +- `Directory.Packages.props` centralizes package IDs and their selected versions. Most + entries reference properties generated in `eng/Version.Details.props`; + `eng/Versions.props` imports those values and adds manually maintained and + compatibility-specific version policy. Trace the package or assembly back to its + product repository instead of changing a version or copying upstream code as a + substitute for fixing the owner. The VMR synchronizes product source in both directions through [code flow](https://github.com/dotnet/dotnet/blob/main/docs/Codeflow-PRs.md): forward flow moves product-repository changes into the VMR, and backflow returns VMR source changes and newly built dependencies to product repositories. Do not edit a mirrored VMR `src/*` -directory for an ordinary component fix. Direct VMR changes are for VMR infrastructure, -integration, servicing, or explicitly coordinated cross-repository work; follow the +directory for an ordinary component fix. Make direct VMR changes only for VMR-owned +infrastructure and pipelines, or when servicing, integration, or cross-repository work is +explicitly coordinated; follow the [VMR contribution guidance](https://github.com/dotnet/dotnet#contribution). Source-build is a validation mode, not an ownership boundary: component-specific source-build behavior belongs with that component, while whole-product source-build From ad7d358ced878666f48a81d3907dcc264d392831 Mon Sep 17 00:00:00 2001 From: Matt Thalman Date: Thu, 23 Jul 2026 09:40:36 -0500 Subject: [PATCH 3/4] Trim multi-repo ownership guidance Remove redundant repository entries and keep the agent guidance focused on ownership boundaries that affect SDK issue routing. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 99b4cd14-14dc-459c-bac7-f984c9d2632b --- .github/copilot-instructions.md | 40 --------------------------------- 1 file changed, 40 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index d0ca2cdd17a2..290fdb21644c 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -53,13 +53,11 @@ workaround merely because the symptom appears through `dotnet`. | Repository | Ownership boundary | | --- | --- | -| [`dotnet/sdk`](https://github.com/dotnet/sdk) | The managed `dotnet` CLI commands and their UX/orchestration; SDK MSBuild tasks, targets, and resolvers; the Template Engine libraries and tools under `src/TemplateEngine`; the `dotnet new` host under `src/Cli/Microsoft.TemplateEngine.Cli`; and common template content under `template_feed`. | | [`dotnet/runtime`](https://github.com/dotnet/runtime) | CLR and Mono, the base class libraries, the native `dotnet` host/muxer and apphost, runtime and reference packs, and runtime-owned deployment tooling such as NativeAOT and ILLink. SDK publish targets integrate with these artifacts but do not own their implementation. | | [`dotnet/roslyn`](https://github.com/dotnet/roslyn) | The C# and Visual Basic compilers, compiler server, compiler APIs, and C#/VB compiler behavior such as language diagnostics and code generation. The SDK supplies inputs and ships Roslyn artifacts; SDK-generated defaults and command wiring remain SDK-owned. The F# compiler is in [`dotnet/fsharp`](https://github.com/dotnet/fsharp). | | [`dotnet/msbuild`](https://github.com/dotnet/msbuild) | The MSBuild engine, evaluation and execution semantics, logging, and core tasks and targets. SDK-specific `Microsoft.NET.*` tasks and targets remain in this repo. | | [`NuGet/NuGet.Client`](https://github.com/NuGet/NuGet.Client) | NuGet restore, package resolution, protocols, and related MSBuild tasks. SDK CLI wrappers and SDK-specific integration remain in this repo. | | [`dotnet/project-system`](https://github.com/dotnet/project-system) | Visual Studio-specific project-system behavior. | -| [`dotnet/templating`](https://github.com/dotnet/templating) | Historical home of the Template Engine. Its source and development moved into `dotnet/sdk` in 2026; make current Template Engine changes in this repo. See the [Template Engine overview](../documentation/TemplateEngine/README.md). | | [`dotnet/dotnet`](https://github.com/dotnet/dotnet) | The Virtual Monolithic Repository (VMR): a synchronized mirror of product repositories plus the infrastructure for building and servicing the integrated .NET product. Product source is mirrored under `src/`; normal component development still belongs in the owning product repository. | Do not infer ownership from a diagnostic ID or generated code alone. C# and Visual Basic @@ -67,44 +65,6 @@ compiler diagnostics and compiler-emitted code belong to Roslyn, but analyzers a generators belong to the repository that implements them, such as `dotnet/runtime` for runtime-library generators or `dotnet/sdk` for SDK analyzers. -The standalone SDK build consumes most sibling components as packages or other build -artifacts. Use these files to identify the exact implementation being consumed: - -- `eng/Version.Details.xml` records flowed dependency versions and source URI/commit. - Unified Build backflow commonly records `dotnet/dotnet` as the source for packages from - several product repositories; that does not transfer ownership to the VMR. When exact - source matters, inspect `src/source-manifest.json` and the corresponding `src/` - directory at the recorded VMR commit, for example `src/runtime`, `src/roslyn`, or - `src/msbuild`. -- `Directory.Packages.props` centralizes package IDs and their selected versions. Most - entries reference properties generated in `eng/Version.Details.props`; - `eng/Versions.props` imports those values and adds manually maintained and - compatibility-specific version policy. Trace the package or assembly back to its - product repository instead of changing a version or copying upstream code as a - substitute for fixing the owner. - -The VMR synchronizes product source in both directions through -[code flow](https://github.com/dotnet/dotnet/blob/main/docs/Codeflow-PRs.md): forward flow -moves product-repository changes into the VMR, and backflow returns VMR source changes and -newly built dependencies to product repositories. Do not edit a mirrored VMR `src/*` -directory for an ordinary component fix. Make direct VMR changes only for VMR-owned -infrastructure and pipelines, or when servicing, integration, or cross-repository work is -explicitly coordinated; follow the -[VMR contribution guidance](https://github.com/dotnet/dotnet#contribution). -Source-build is a validation mode, not an ownership boundary: component-specific -source-build behavior belongs with that component, while whole-product source-build -orchestration belongs in the VMR. - -For a cross-repository issue: - -1. Identify the executable, assembly, task, target, or package that implements the - behavior, and inspect the version actually consumed by this checkout. -2. Put the semantic fix and its primary tests in the owning repository. Keep only genuine - SDK orchestration, defaults, compatibility, or integration changes in `dotnet/sdk`. -3. If multiple components must change, keep each change and its tests with its owner, then - consume the flowed build. Validate the integrated VMR when the issue depends on an - exact component combination, source-build, or cross-repository target hooks. - ### Architecture and major components The managed CLI dispatches commands registered in From 07e0aaf7c477def1d29c1f59a83b15f804e99f91 Mon Sep 17 00:00:00 2001 From: Matt Thalman Date: Thu, 23 Jul 2026 09:56:56 -0500 Subject: [PATCH 4/4] Document FSharp ownership separately Give dotnet/fsharp its own repository-boundary row and keep Roslyn ownership focused on C# and Visual Basic. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Copilot-Session: 99b4cd14-14dc-459c-bac7-f984c9d2632b --- .github/copilot-instructions.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 290fdb21644c..0b46b329029e 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -54,7 +54,8 @@ workaround merely because the symptom appears through `dotnet`. | Repository | Ownership boundary | | --- | --- | | [`dotnet/runtime`](https://github.com/dotnet/runtime) | CLR and Mono, the base class libraries, the native `dotnet` host/muxer and apphost, runtime and reference packs, and runtime-owned deployment tooling such as NativeAOT and ILLink. SDK publish targets integrate with these artifacts but do not own their implementation. | -| [`dotnet/roslyn`](https://github.com/dotnet/roslyn) | The C# and Visual Basic compilers, compiler server, compiler APIs, and C#/VB compiler behavior such as language diagnostics and code generation. The SDK supplies inputs and ships Roslyn artifacts; SDK-generated defaults and command wiring remain SDK-owned. The F# compiler is in [`dotnet/fsharp`](https://github.com/dotnet/fsharp). | +| [`dotnet/roslyn`](https://github.com/dotnet/roslyn) | The C# and Visual Basic compilers, compiler server, compiler APIs, and C#/VB compiler behavior such as language diagnostics and code generation. The SDK supplies inputs and ships Roslyn artifacts; SDK-generated defaults and command wiring remain SDK-owned. | +| [`dotnet/fsharp`](https://github.com/dotnet/fsharp) | The F# compiler and F#-specific tooling. | | [`dotnet/msbuild`](https://github.com/dotnet/msbuild) | The MSBuild engine, evaluation and execution semantics, logging, and core tasks and targets. SDK-specific `Microsoft.NET.*` tasks and targets remain in this repo. | | [`NuGet/NuGet.Client`](https://github.com/NuGet/NuGet.Client) | NuGet restore, package resolution, protocols, and related MSBuild tasks. SDK CLI wrappers and SDK-specific integration remain in this repo. | | [`dotnet/project-system`](https://github.com/dotnet/project-system) | Visual Studio-specific project-system behavior. |