dotnet · adegeo · Jul 22, 2026 · Jul 23, 2026 · Jul 23, 2026 · Jul 23, 2026
@@ -77,7 +77,7 @@ In this quickstart, you create a minimal Model Context Protocol (MCP) server usi
     - **Framework**: Select the target .NET framework.
     - **MCP Server Transport Type**: Choose between creating a **local** (stdio) or a **remote** (http) MCP server.
     - **Enable native AOT (Ahead-Of-Time) publish**: Enable your MCP server to be self-contained and compiled to native code. For more information, see the [Native AOT deployment guide](../../core/deploying/native-aot/index.md).
-    - **Enable self-contained publish**: Enable your MCP server to be published as a self-contained executable. For more information, see the [Self-contained deployment section of the .NET application publishing guide](../../core/deploying/index.md#self-contained-deployment).
+    - **Enable self-contained publish**: Enable your MCP server to be published as a self-contained executable. For more information, see the [Self-contained deployment section of the .NET application publishing guide](../../core/deploying/index.md#publish-as-self-contained).
 
     Choose your preferred options or keep the default ones, and then select **Create**.
 
@@ -124,7 +124,7 @@ In this quickstart, you create a minimal Model Context Protocol (MCP) server usi
     - **Framework**: Select the target .NET framework.
     - **MCP Server Transport Type**: Choose between creating a **local** (stdio) or a **remote** (http) MCP server.
     - **Enable native AOT (Ahead-Of-Time) publish**: Enable your MCP server to be self-contained and compiled to native code. For more information, see the [Native AOT deployment guide](../../core/deploying/native-aot/index.md).
-    - **Enable self-contained publish**: Enable your MCP server to be published as a self-contained executable. For more information, see the [Self-contained deployment section of the .NET application publishing guide](../../core/deploying/index.md#self-contained-deployment).
+    - **Enable self-contained publish**: Enable your MCP server to be published as a self-contained executable. For more information, see the [Self-contained deployment section of the .NET application publishing guide](../../core/deploying/index.md#publish-as-self-contained).
 
     ![MCP Server Template Options](../media/build-mcp-server/vscode-mcp-server-template-options.png)
 
@@ -151,7 +151,7 @@ In this quickstart, you create a minimal Model Context Protocol (MCP) server usi
     - **Framework**: Select the target .NET framework.
     - **MCP Server Transport Type**: Choose between creating a **local** (stdio) or a **remote** (http) MCP server.
     - **Enable native AOT (Ahead-Of-Time) publish**: Enable your MCP server to be self-contained and compiled to native code. For more information, see the [Native AOT deployment guide](../../core/deploying/native-aot/index.md).
-    - **Enable self-contained publish**: Enable your MCP server to be published as a self-contained executable. For more information, see the [Self-contained deployment section of the .NET application publishing guide](../../core/deploying/index.md#self-contained-deployment).
+    - **Enable self-contained publish**: Enable your MCP server to be published as a self-contained executable. For more information, see the [Self-contained deployment section of the .NET application publishing guide](../../core/deploying/index.md#publish-as-self-contained).
 
     ![Template options for an MCP Server in .NET CLI](../media/build-mcp-server/cli-mcp-server-template-options.png)
 

@@ -457,7 +457,7 @@ The .NET team provides some basic variants in [dotnet/](https://hub.docker.com/r
 - **sdk**: for development and build scenarios
 - **aspnet**: for ASP.NET production scenarios
 - **runtime**: for .NET production scenarios
-- **runtime-deps**: for production scenarios of [self-contained applications](../../../core/deploying/index.md#self-contained-deployment)
+- **runtime-deps**: for production scenarios of [self-contained applications](../../../core/deploying/index.md#publish-as-self-contained)
 
 For faster startup, runtime images also automatically set aspnetcore\_urls to port 80 and use Ngen to create a native image cache of assemblies.
 

@@ -5,7 +5,7 @@ ms.date: 10/05/2023
 ---
 # --arch option doesn't imply self-contained
 
-Up until now, the `--arch` option for `dotnet` CLI commands such as [dotnet publish](../../../tools/dotnet-publish.md) implied that the app was [self-contained](../../../deploying/index.md#self-contained-deployment). The behavior of the `--arch` option has now been changed to match that of the `--runtime` option, and it no longer implies that an app is self-contained.
+Up until now, the `--arch` option for `dotnet` CLI commands such as [dotnet publish](../../../tools/dotnet-publish.md) implied that the app was [self-contained](../../../deploying/index.md#publish-as-self-contained). The behavior of the `--arch` option has now been changed to match that of the `--runtime` option, and it no longer implies that an app is self-contained.
 
 ## Previous behavior
 

@@ -5,7 +5,7 @@ ms.date: 06/05/2023
 ---
 # Runtime-specific apps no longer self-contained
 
-Runtime-specific apps, or .NET apps with a `RuntimeIdentifier`, are no longer [self-contained](../../../deploying/index.md#self-contained-deployment) by default. Instead, they are [framework-dependent](../../../deploying/index.md#framework-dependent-deployment) by default.
+Runtime-specific apps, or .NET apps with a `RuntimeIdentifier`, are no longer [self-contained](../../../deploying/index.md#publish-as-self-contained) by default. Instead, they are [framework-dependent](../../../deploying/index.md#publish-as-framework-dependent) by default.
 
 This is a breaking change in the following situations:
 

@@ -58,6 +58,9 @@ dotnet publish -c Release -f net9.0
 
 The default output directory of the [`dotnet publish`](../tools/dotnet-publish.md) command is `./bin/<BUILD-CONFIGURATION>/<TFM>/publish/`. For example, `dotnet publish -c Release -f net9.0` publishes to `./bin/Release/net9.0/publish/`. However, you can opt in to a simplified output path and folder structure for all build outputs. For more information, see [Artifacts output layout](../sdk/artifacts-output.md).
 
+> [!IMPORTANT]
+> When you skip the build step during publish by passing the `--no-build` parameter, use the same options you used when you built the app, including target framework and build mode. For example, don't build as a framework-dependent app and then publish as a self-contained app.
+
 ::: zone-end
 
 ::: zone pivot="visualstudio"
@@ -107,25 +110,21 @@ dotnet publish -c Release -r <RID>
 
 For a list of runtime identifiers, see [Runtime Identifier (RID) catalog](../rid-catalog.md).
 
-::: zone pivot="cli,vscode"
-
 ## Quick reference
 
-The following table provides quick examples of how to publish your app.
+The following table provides quick examples of how to publish your app with the `dotnet` CLI:
 
-| Publish Mode | Command |
+| Publish mode | Command |
 |--|--|
-| [Framework-dependent deployment](#framework-dependent-deployment) | `dotnet publish -c Release [-r <RID>]` |
-| [Framework-dependent deployment (DLL)](#framework-dependent-deployment) | `dotnet publish -c Release -p:UseAppHost=false` |
-| [Self-contained deployment](#self-contained-deployment) | `dotnet publish -c Release [-r <RID>] --self-contained true` |
-| [Single-file deployment](#single-file-deployment) | `dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true` |
-| [Native AOT deployment](#native-aot-deployment) | `dotnet publish -c Release [-r <RID>] -p:PublishAot=true` |
-| [ReadyToRun deployment](#readytorun-deployment) | `dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true` |
+| [Framework-dependent deployment](#publish-as-framework-dependent) | `dotnet publish -c Release [-r <RID>]` |
+| [Framework-dependent deployment (DLL)](#cross-platform-dll-deployment) | `dotnet publish -c Release -p:UseAppHost=false` |
+| [Self-contained deployment](#publish-as-self-contained) | `dotnet publish -c Release [-r <RID>] --self-contained true` |
+| [Single-file deployment](#publish-as-single-file) | `dotnet publish -c Release [-r <RID>] -p:PublishSingleFile=true` |
+| [Native AOT deployment](#publish-as-native-aot) | `dotnet publish -c Release [-r <RID>] -p:PublishAot=true` |
+| [ReadyToRun deployment](#publish-as-readytorun) | `dotnet publish -c Release [-r <RID>] -p:PublishReadyToRun=true` |
 | [Container deployment](#container-deployment) | `dotnet publish -c Release [-r <RID>] -t:PublishContainer` |
 
-::: zone-end
-
-## Framework-dependent deployment
+## Publish as framework-dependent
 
 Framework-dependent deployment is the default mode when you publish from either the CLI or Visual Studio. In this mode, a platform-specific executable is created that can be used to start your app. The platform-specific executable is named something similar to `myapp.exe` on Windows or just `myapp` on other platforms.
 
@@ -247,11 +246,11 @@ dotnet publish -c Release -p:UseAppHost=false
 
 ::: zone-end
 
-## Self-contained deployment
+## Publish as self-contained
 
 When you publish a self-contained deployment (SCD), the publishing process creates a platform-specific executable. Publishing an SCD includes all required .NET files to run your app but it doesn't include the native dependencies of .NET. These dependencies must be present on the environment before the app runs.
 
-Publishing an SCD creates an app that doesn't roll forward to the latest available .NET security patch. For more information on version binding at compile time, see [Select the .NET version to use](../versions/selection.md#self-contained-deployments-include-the-selected-runtime).
+Publishing an SCD creates an app that doesn't roll forward to the latest available .NET security patch. For more information on version binding at compile time, see [Select the .NET version to use](../versions/selection.md#framework-dependent-apps-roll-forward).
 
 **Advantages**
 
@@ -296,7 +295,7 @@ dotnet publish -c Release -r <RID> --self-contained true
 
 ::: zone-end
 
-## Single-file deployment
+## Publish as single-file
 
 When you publish your app as a single-file deployment, all application-dependent files are bundled into a single binary. This deployment model is available for both framework-dependent and self-contained applications, providing an attractive option to deploy and distribute your application as a single file.
 
@@ -314,7 +313,7 @@ Single-file apps are always OS and architecture specific. You need to publish fo
 - **Slower startup**: Files must be extracted at runtime, which can impact startup performance.
 - **Platform-specific**: Must publish separate files for each target platform.
 
-Single-file deployment can be combined with other optimizations like [trimming](trimming/trim-self-contained.md) and [ReadyToRun compilation](#readytorun-deployment) for further optimization.
+Single-file deployment can be combined with other optimizations like [trimming](trimming/trim-self-contained.md) and [ReadyToRun compilation](#publish-as-native-aot) for further optimization.
 
 For more information about single-file deployment, see [Single-file deployment](single-file/overview.md).
 
@@ -349,7 +348,7 @@ dotnet publish -c Release -r <RID> -p:PublishSingleFile=true
 
 ::: zone-end
 
-## Native AOT deployment
+## Publish as native AOT
 
 Native AOT deployment compiles your app directly to native code, eliminating the need for a runtime. This publishing option uses **self-contained deployment** mode, as the compiled native code must include everything needed to run the application. This results in faster startup times and reduced memory usage, but comes with some limitations on supported features.
 
@@ -411,7 +410,7 @@ For more information about Native AOT deployment, see [Native AOT deployment](na
 
 ::: zone-end
 
-## ReadyToRun deployment
+## Publish as ReadyToRun
 
 When you publish your app with ReadyToRun compilation, your application assemblies are compiled as ReadyToRun (R2R) format. R2R is a form of ahead-of-time (AOT) compilation that improves startup performance by reducing the amount of work the just-in-time (JIT) compiler needs to do as your application loads. This publishing option can be used with both **framework-dependent** and **self-contained** deployment modes.
 

@@ -8,11 +8,11 @@ ai-usage: ai-assisted
 
 # Native AOT deployment
 
-Publishing your app as *Native AOT* produces an app that's [self-contained](../index.md#self-contained-deployment) and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
+Publishing your app as *Native AOT* produces an app that's [self-contained](../index.md#publish-as-self-contained) and that has been ahead-of-time (AOT) compiled to native code. Native AOT apps have faster startup time and smaller memory footprints. These apps can run on machines that don't have the .NET runtime installed.
 
 The benefit of Native AOT is most significant for workloads with a high number of deployed instances, such as cloud infrastructure and hyper-scale services. .NET 8 adds [ASP.NET Core support for native AOT](/aspnet/core/fundamentals/native-aot).
 
-The Native AOT deployment model uses an ahead-of-time compiler to compile IL to native code at the time of publish. Native AOT apps don't use a just-in-time (JIT) compiler when the application runs. Native AOT apps can run in restricted environments where a JIT isn't allowed. Native AOT applications target a specific runtime environment, such as Linux x64 or Windows x64, just like publishing a [self-contained app](../index.md#self-contained-deployment).
+The Native AOT deployment model uses an ahead-of-time compiler to compile IL to native code at the time of publish. Native AOT apps don't use a just-in-time (JIT) compiler when the application runs. Native AOT apps can run in restricted environments where a JIT isn't allowed. Native AOT applications target a specific runtime environment, such as Linux x64 or Windows x64, just like publishing a [self-contained app](../index.md#publish-as-self-contained).
 
 ## Prerequisites
 
@@ -173,7 +173,7 @@ Native AOT apps have the following limitations:
 - Windows: No built-in COM.
 - Requires trimming, which has [limitations](../trimming/incompatibilities.md).
 - Implies compilation into a single file, which has known [incompatibilities](../single-file/overview.md#api-incompatibility).
-- Apps include required runtime libraries (just like [self-contained apps](../index.md#self-contained-deployment), increasing their size as compared to framework-dependent apps).
+- Apps include required runtime libraries (just like [self-contained apps](../index.md#publish-as-self-contained), increasing their size as compared to framework-dependent apps).
 - <xref:System.Linq.Expressions> always use their interpreted form, which is slower than runtime generated compiled code.
 - Generic parameters substituted with struct type arguments have specialized code generated for each instantiation. In the dynamic runtime, many instantiations are generated on-demand. In Native AOT, all instantiations are pre-generated. This can have significant impact to the disk size of the application. Generic virtual methods and generic instance methods will also have an instantiation for every implementing or overriding type.
 - Not all the runtime libraries are fully annotated to be Native AOT compatible. That is, some warnings in the runtime libraries aren't actionable by end developers.

@@ -83,7 +83,7 @@ These symbols will be placed in the publish directory and for Windows will have
 
 ## Composite ReadyToRun
 
-Normal ReadyToRun compilation produces binaries that can be serviced and manipulated individually. Starting in .NET 6, support for Composite ReadyToRun compilation has been added. Composite ReadyToRun compiles a set of assemblies that must be distributed together. This has the advantage that the compiler is able to perform better optimizations and reduces the set of methods that cannot be compiled via the ReadyToRun process. However, as a tradeoff, compilation speed is significantly decreased, and the overall file size of the application is significantly increased. Due to these tradeoffs, use of Composite ReadyToRun is only recommended for applications that disable [Tiered Compilation](../runtime-config/compilation.md#tiered-compilation) or applications running on Linux that are seeking the best startup time with [self-contained](index.md#self-contained-deployment) deployment. To enable composite ReadyToRun compilation, specify the `<PublishReadyToRunComposite>` property.
+Normal ReadyToRun compilation produces binaries that can be serviced and manipulated individually. Starting in .NET 6, support for Composite ReadyToRun compilation has been added. Composite ReadyToRun compiles a set of assemblies that must be distributed together. This has the advantage that the compiler is able to perform better optimizations and reduces the set of methods that cannot be compiled via the ReadyToRun process. However, as a tradeoff, compilation speed is significantly decreased, and the overall file size of the application is significantly increased. Due to these tradeoffs, use of Composite ReadyToRun is only recommended for applications that disable [Tiered Compilation](../runtime-config/compilation.md#tiered-compilation) or applications running on Linux that are seeking the best startup time with [self-contained](index.md#publish-as-self-contained) deployment. To enable composite ReadyToRun compilation, specify the `<PublishReadyToRunComposite>` property.
 
 ```xml
 <PropertyGroup>
@@ -92,7 +92,7 @@ Normal ReadyToRun compilation produces binaries that can be serviced and manipul
 ```
 
 > [!NOTE]
-> In .NET 6, Composite ReadyToRun is only supported for [self-contained](index.md#self-contained-deployment) deployment.
+> In .NET 6, Composite ReadyToRun is only supported for [self-contained](index.md#publish-as-self-contained) deployment.
 
 ## Cross platform/architecture restrictions