From 42c2e398f1b7d43df32a12180daeeffbdc475262 Mon Sep 17 00:00:00 2001 From: Azure SDK Bot <53356347+azure-sdk@users.noreply.github.com> Date: Thu, 21 Aug 2025 06:38:54 -0700 Subject: [PATCH 1/7] Update package index with latest published versions (#48049) --- docs/azure/includes/dotnet-all.md | 4 ++-- docs/azure/includes/dotnet-new.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/azure/includes/dotnet-all.md b/docs/azure/includes/dotnet-all.md index 05bdcdd2df041..88b42db2a0eca 100644 --- a/docs/azure/includes/dotnet-all.md +++ b/docs/azure/includes/dotnet-all.md @@ -1,7 +1,7 @@ | Name | Package | Docs | Source | | ---- | ------- | ---- | ------ | | AI Agents Persistent | NuGet [1.1.0](https://www.nuget.org/packages/Azure.AI.Agents.Persistent/1.1.0)
NuGet [1.2.0-beta.2](https://www.nuget.org/packages/Azure.AI.Agents.Persistent/1.2.0-beta.2) | [docs](/dotnet/api/overview/azure/AI.Agents.Persistent-readme) | GitHub [1.1.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Agents.Persistent_1.1.0/sdk/ai/Azure.AI.Agents.Persistent/)
GitHub [1.2.0-beta.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Agents.Persistent_1.2.0-beta.2/sdk/ai/Azure.AI.Agents.Persistent/) | -| AI Foundry | NuGet [1.0.0-beta.10](https://www.nuget.org/packages/Azure.AI.Projects/1.0.0-beta.10) | [docs](/dotnet/api/overview/azure/AI.Projects-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.10](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Projects_1.0.0-beta.10/sdk/ai/Azure.AI.Projects/) | +| AI Foundry | NuGet [1.0.0-beta.11](https://www.nuget.org/packages/Azure.AI.Projects/1.0.0-beta.11) | [docs](/dotnet/api/overview/azure/AI.Projects-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.11](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Projects_1.0.0-beta.11/sdk/ai/Azure.AI.Projects/) | | AI Model Inference | NuGet [1.0.0-beta.5](https://www.nuget.org/packages/Azure.AI.Inference/1.0.0-beta.5) | [docs](/dotnet/api/overview/azure/AI.Inference-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.5](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Inference_1.0.0-beta.5/sdk/ai/Azure.AI.Inference/) | | Anomaly Detector | NuGet [3.0.0-preview.7](https://www.nuget.org/packages/Azure.AI.AnomalyDetector/3.0.0-preview.7) | [docs](/dotnet/api/overview/azure/AI.AnomalyDetector-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [3.0.0-preview.7](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.AnomalyDetector_3.0.0-preview.7/sdk/anomalydetector/Azure.AI.AnomalyDetector/) | | App Configuration | NuGet [1.6.1](https://www.nuget.org/packages/Azure.Data.AppConfiguration/1.6.1) | [docs](/dotnet/api/overview/azure/Data.AppConfiguration-readme) | GitHub [1.6.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Data.AppConfiguration_1.6.1/sdk/appconfiguration/Azure.Data.AppConfiguration/) | @@ -29,7 +29,7 @@ | Conversational Language Understanding | NuGet [1.1.0](https://www.nuget.org/packages/Azure.AI.Language.Conversations/1.1.0)
NuGet [2.0.0-beta.3](https://www.nuget.org/packages/Azure.AI.Language.Conversations/2.0.0-beta.3) | [docs](/dotnet/api/overview/azure/AI.Language.Conversations-readme) | GitHub [1.1.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Language.Conversations_1.1.0/sdk/cognitivelanguage/Azure.AI.Language.Conversations/)
GitHub [2.0.0-beta.3](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Language.Conversations_2.0.0-beta.3/sdk/cognitivelanguage/Azure.AI.Language.Conversations/) | | Conversations Authoring | NuGet [1.0.0-beta.2](https://www.nuget.org/packages/Azure.AI.Language.Conversations.Authoring/1.0.0-beta.2) | [docs](/dotnet/api/overview/azure/AI.Language.Conversations.Authoring-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Language.Conversations.Authoring_1.0.0-beta.2/sdk/cognitivelanguage/Azure.AI.Language.Conversations.Authoring/) | | Core - Client - AMQP | NuGet [1.3.1](https://www.nuget.org/packages/Azure.Core.Amqp/1.3.1) | [docs](/dotnet/api/overview/azure/Core.Amqp-readme) | GitHub [1.3.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Core.Amqp_1.3.1/sdk/core/Azure.Core.Amqp/) | -| Core - Client - Core | NuGet [1.47.2](https://www.nuget.org/packages/Azure.Core/1.47.2) | [docs](/dotnet/api/overview/azure/Core-readme) | GitHub [1.47.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Core_1.47.2/sdk/core/Azure.Core/) | +| Core - Client - Core | NuGet [1.47.3](https://www.nuget.org/packages/Azure.Core/1.47.3) | [docs](/dotnet/api/overview/azure/Core-readme) | GitHub [1.47.3](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Core_1.47.3/sdk/core/Azure.Core/) | | Core Newtonsoft Json | NuGet [2.0.0](https://www.nuget.org/packages/Microsoft.Azure.Core.NewtonsoftJson/2.0.0) | [docs](/dotnet/api/overview/azure/Microsoft.Azure.Core.NewtonsoftJson-readme) | GitHub [2.0.0](https://github.com/Azure/azure-sdk-for-net/tree/Microsoft.Azure.Core.NewtonsoftJson_2.0.0/sdk/core/Microsoft.Azure.Core.NewtonsoftJson/) | | Core WCF Storage Queues | NuGet [1.0.0-beta.1](https://www.nuget.org/packages/Microsoft.CoreWCF.Azure.StorageQueues/1.0.0-beta.1) | [docs](/dotnet/api/overview/azure/Microsoft.CoreWCF.Azure.StorageQueues-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.1](https://github.com/Azure/azure-sdk-for-net/tree/Microsoft.CoreWCF.Azure.StorageQueues_1.0.0-beta.1/sdk/extension-wcf/Microsoft.CoreWCF.Azure.StorageQueues/) | | Data Movement | NuGet [12.2.1](https://www.nuget.org/packages/Azure.Storage.DataMovement/12.2.1) | [docs](/dotnet/api/overview/azure/Storage.DataMovement-readme) | GitHub [12.2.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Storage.DataMovement_12.2.1/sdk/storage/Azure.Storage.DataMovement/) | diff --git a/docs/azure/includes/dotnet-new.md b/docs/azure/includes/dotnet-new.md index 60cc952a098f7..f77f23e176816 100644 --- a/docs/azure/includes/dotnet-new.md +++ b/docs/azure/includes/dotnet-new.md @@ -1,7 +1,7 @@ | Name | Package | Docs | Source | | ---- | ------- | ---- | ------ | | AI Agents Persistent | NuGet [1.1.0](https://www.nuget.org/packages/Azure.AI.Agents.Persistent/1.1.0)
NuGet [1.2.0-beta.2](https://www.nuget.org/packages/Azure.AI.Agents.Persistent/1.2.0-beta.2) | [docs](/dotnet/api/overview/azure/AI.Agents.Persistent-readme) | GitHub [1.1.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Agents.Persistent_1.1.0/sdk/ai/Azure.AI.Agents.Persistent/)
GitHub [1.2.0-beta.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Agents.Persistent_1.2.0-beta.2/sdk/ai/Azure.AI.Agents.Persistent/) | -| AI Foundry | NuGet [1.0.0-beta.10](https://www.nuget.org/packages/Azure.AI.Projects/1.0.0-beta.10) | [docs](/dotnet/api/overview/azure/AI.Projects-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.10](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Projects_1.0.0-beta.10/sdk/ai/Azure.AI.Projects/) | +| AI Foundry | NuGet [1.0.0-beta.11](https://www.nuget.org/packages/Azure.AI.Projects/1.0.0-beta.11) | [docs](/dotnet/api/overview/azure/AI.Projects-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.11](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Projects_1.0.0-beta.11/sdk/ai/Azure.AI.Projects/) | | AI Model Inference | NuGet [1.0.0-beta.5](https://www.nuget.org/packages/Azure.AI.Inference/1.0.0-beta.5) | [docs](/dotnet/api/overview/azure/AI.Inference-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.5](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Inference_1.0.0-beta.5/sdk/ai/Azure.AI.Inference/) | | Anomaly Detector | NuGet [3.0.0-preview.7](https://www.nuget.org/packages/Azure.AI.AnomalyDetector/3.0.0-preview.7) | [docs](/dotnet/api/overview/azure/AI.AnomalyDetector-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [3.0.0-preview.7](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.AnomalyDetector_3.0.0-preview.7/sdk/anomalydetector/Azure.AI.AnomalyDetector/) | | App Configuration | NuGet [1.6.1](https://www.nuget.org/packages/Azure.Data.AppConfiguration/1.6.1) | [docs](/dotnet/api/overview/azure/Data.AppConfiguration-readme) | GitHub [1.6.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Data.AppConfiguration_1.6.1/sdk/appconfiguration/Azure.Data.AppConfiguration/) | @@ -31,7 +31,7 @@ | Conversational Language Understanding | NuGet [1.1.0](https://www.nuget.org/packages/Azure.AI.Language.Conversations/1.1.0)
NuGet [2.0.0-beta.3](https://www.nuget.org/packages/Azure.AI.Language.Conversations/2.0.0-beta.3) | [docs](/dotnet/api/overview/azure/AI.Language.Conversations-readme) | GitHub [1.1.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Language.Conversations_1.1.0/sdk/cognitivelanguage/Azure.AI.Language.Conversations/)
GitHub [2.0.0-beta.3](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Language.Conversations_2.0.0-beta.3/sdk/cognitivelanguage/Azure.AI.Language.Conversations/) | | Conversations Authoring | NuGet [1.0.0-beta.2](https://www.nuget.org/packages/Azure.AI.Language.Conversations.Authoring/1.0.0-beta.2) | [docs](/dotnet/api/overview/azure/AI.Language.Conversations.Authoring-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.AI.Language.Conversations.Authoring_1.0.0-beta.2/sdk/cognitivelanguage/Azure.AI.Language.Conversations.Authoring/) | | Core - Client - AMQP | NuGet [1.3.1](https://www.nuget.org/packages/Azure.Core.Amqp/1.3.1) | [docs](/dotnet/api/overview/azure/Core.Amqp-readme) | GitHub [1.3.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Core.Amqp_1.3.1/sdk/core/Azure.Core.Amqp/) | -| Core - Client - Core | NuGet [1.47.2](https://www.nuget.org/packages/Azure.Core/1.47.2) | [docs](/dotnet/api/overview/azure/Core-readme) | GitHub [1.47.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Core_1.47.2/sdk/core/Azure.Core/) | +| Core - Client - Core | NuGet [1.47.3](https://www.nuget.org/packages/Azure.Core/1.47.3) | [docs](/dotnet/api/overview/azure/Core-readme) | GitHub [1.47.3](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Core_1.47.3/sdk/core/Azure.Core/) | | Core Newtonsoft Json | NuGet [2.0.0](https://www.nuget.org/packages/Microsoft.Azure.Core.NewtonsoftJson/2.0.0) | [docs](/dotnet/api/overview/azure/Microsoft.Azure.Core.NewtonsoftJson-readme) | GitHub [2.0.0](https://github.com/Azure/azure-sdk-for-net/tree/Microsoft.Azure.Core.NewtonsoftJson_2.0.0/sdk/core/Microsoft.Azure.Core.NewtonsoftJson/) | | Core WCF Storage Queues | NuGet [1.0.0-beta.1](https://www.nuget.org/packages/Microsoft.CoreWCF.Azure.StorageQueues/1.0.0-beta.1) | [docs](/dotnet/api/overview/azure/Microsoft.CoreWCF.Azure.StorageQueues-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.1](https://github.com/Azure/azure-sdk-for-net/tree/Microsoft.CoreWCF.Azure.StorageQueues_1.0.0-beta.1/sdk/extension-wcf/Microsoft.CoreWCF.Azure.StorageQueues/) | | Data Movement | NuGet [12.2.1](https://www.nuget.org/packages/Azure.Storage.DataMovement/12.2.1) | [docs](/dotnet/api/overview/azure/Storage.DataMovement-readme) | GitHub [12.2.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.Storage.DataMovement_12.2.1/sdk/storage/Azure.Storage.DataMovement/) | From d34a1beb1c5ab841a3092abf7477e7924681b554 Mon Sep 17 00:00:00 2001 From: Mariam Abdullah <122357303+mariam-abdulla@users.noreply.github.com> Date: Thu, 21 Aug 2025 16:12:52 +0200 Subject: [PATCH 2/7] remove --directory (#48054) --- docs/core/tools/dotnet-test.md | 17 +++-------------- 1 file changed, 3 insertions(+), 14 deletions(-) diff --git a/docs/core/tools/dotnet-test.md b/docs/core/tools/dotnet-test.md index a5f765d6f3b59..a273970afb8de 100644 --- a/docs/core/tools/dotnet-test.md +++ b/docs/core/tools/dotnet-test.md @@ -422,7 +422,6 @@ For more information and examples on how to use selective unit test filtering, s dotnet test [--project ] [--solution ] - [--directory ] [--test-modules ] [--root-directory ] [--max-parallel-test-modules ] @@ -458,20 +457,16 @@ With Microsoft Testing Platform, `dotnet test` operates faster than with VSTest. #### Options > [!NOTE] -> You can use only one of the following options at a time: `--project`, `--solution`, `--directory`, or `--test-modules`. These options can't be combined. +> You can use only one of the following options at a time: `--project`, `--solution`, or `--test-modules`. These options can't be combined. > In addition, when using `--test-modules`, you can't specify `--arch`, `--configuration`, `--framework`, `--os`, or `--runtime`. These options are not relevant for an already-built module. - **`--project `** - Specifies the path to the test project. + Specifies the path of the project file to run (folder name or full path). If not specified, it defaults to the current directory. - **`--solution `** - Specifies the path to the solution. - -- **`--directory `** - - Specifies the path to a directory that contains a project or a solution. + Specifies the path of the solution file to run (folder name or full path). If not specified, it defaults to the current directory. - **`--test-modules `** @@ -578,12 +573,6 @@ With Microsoft Testing Platform, `dotnet test` operates faster than with VSTest. dotnet test --solution ./TestProjects/TestProjects.sln ``` -- Run the tests in a solution or project that can be found in the `TestProjects` directory: - - ```dotnetcli - dotnet test --directory ./TestProjects - ``` - - Run the tests using `TestProject.dll` assembly: ```dotnetcli From 12dcd61c59bba4e9ae908f9fa6161d10f4d52c49 Mon Sep 17 00:00:00 2001 From: Olabamiji Oyetubo <60369677+bigboybamo@users.noreply.github.com> Date: Thu, 21 Aug 2025 07:18:07 -0700 Subject: [PATCH 3/7] Static instance parameters (#48056) * Update access-modifiers.md Added description for file access type modifier * Update Program.cs Add an example to show parameterless static and instance constructors in a single class. * Update constructors.md Mention Static and instance constructor definiton --- .../classes-and-structs/constructors.md | 4 ++++ .../snippets/constructors/Program.cs | 17 +++++++++++++++++ 2 files changed, 21 insertions(+) diff --git a/docs/csharp/programming-guide/classes-and-structs/constructors.md b/docs/csharp/programming-guide/classes-and-structs/constructors.md index 770a31d9aac98..c8fb566e7083b 100644 --- a/docs/csharp/programming-guide/classes-and-structs/constructors.md +++ b/docs/csharp/programming-guide/classes-and-structs/constructors.md @@ -56,6 +56,10 @@ You can also define a static constructor with an expression body definition, as For more information and examples, see [Static Constructors](./static-constructors.md). +A class can also have **both** an Instance and Static constructor defined, and they can each be defined without parameters. + +:::code source="./snippets/constructors/Program.cs" id="DualConstructor"::: + ## Partial constructors Beginning with C# 14, you can declare *partial constructors* in a partial class or struct. Any partial constructor must have a *defining declaration* and an *implementing declaration*. The signatures of the declaring and implementing partial constructors must match according to the rules of [partial members](./partial-classes-and-methods.md#partial-members). The defining declaration of the partial constructor can't use the `: base()` or `: this()` constructor initializer. You add any constructor initializer must be added on the implementing declaration. diff --git a/docs/csharp/programming-guide/classes-and-structs/snippets/constructors/Program.cs b/docs/csharp/programming-guide/classes-and-structs/snippets/constructors/Program.cs index 9cd7ee626742a..434082552b1c9 100644 --- a/docs/csharp/programming-guide/classes-and-structs/snippets/constructors/Program.cs +++ b/docs/csharp/programming-guide/classes-and-structs/snippets/constructors/Program.cs @@ -72,3 +72,20 @@ public required T Contents } // +// +public class Example +{ + static Example() + { + Console.WriteLine("Static constructor called."); + } + + public Example() + { + Console.WriteLine("Instance constructor called."); + } + + // Remaining implementation of Child class. +} +// + From e12212912072f74edfac055eb7cffce11d328136 Mon Sep 17 00:00:00 2001 From: Copilot <198982749+Copilot@users.noreply.github.com> Date: Thu, 21 Aug 2025 11:04:40 -0700 Subject: [PATCH 4/7] Fix incorrect architecture name for macOS (#46383) --- docs/core/deploying/native-aot/cross-compile.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/deploying/native-aot/cross-compile.md b/docs/core/deploying/native-aot/cross-compile.md index 07bf01b93596a..0101041408753 100644 --- a/docs/core/deploying/native-aot/cross-compile.md +++ b/docs/core/deploying/native-aot/cross-compile.md @@ -26,7 +26,7 @@ Cross-compiling from x64 Windows to ARM64 Windows or vice versa works as long as ## Mac -MacOS provides the x64 and amd64 toolchains in the default XCode install. +MacOS provides the x64 and arm64 toolchains in the default XCode install. ## Linux From 74a2221c059b85a9b87c59c61b3ab7ab87f5b47e Mon Sep 17 00:00:00 2001 From: "Andy (Steve) De George" <67293991+adegeo@users.noreply.github.com> Date: Thu, 21 Aug 2025 14:20:00 -0700 Subject: [PATCH 5/7] Clarify the publishing articles by removing "deploy" where appropriate and merge similar info (#47079) * Temp * Temp * final updates * Minor * Rename and rewrite * Redirect, TOC, links * Temp * Almost final draft of rewriting the publishing intro article. * Reset copilot * Extra descriptions * Move cli parameters to include * move table * Change header to bold * Fix bugs * Add info about FDD lookups * Remove my temp code * Fix indentation * Add container * Handle what acro I can... * Fix cross links to publishing * Redirect deploy/publish articles * Fix other links * Remove sample code no longer unsed * More bookmark changes * fix redirect * Fix links; link to tutorials * Fix that link that snuck through! * ugh * Apply suggestions from code review Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --------- Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> --- .openpublishing.redirection.core.json | 8 + ...i-container-applications-docker-compose.md | 2 +- .../sdk/6.0/apphost-generated-for-macos.md | 2 +- .../core/compatibility/sdk/8.0/arch-option.md | 2 +- .../sdk/8.0/runtimespecific-app-default.md | 2 +- docs/core/deploying/deploy-with-cli.md | 175 ------ docs/core/deploying/deploy-with-vs.md | 307 ---------- docs/core/deploying/includes/cli-c-release.md | 3 + .../deploying/includes/cli-r-rid-optional.md | 3 + docs/core/deploying/includes/cli-r-rid.md | 3 + docs/core/deploying/index.md | 527 ++++++++++++++---- docs/core/deploying/native-aot/index.md | 6 +- docs/core/deploying/ready-to-run.md | 4 +- docs/core/deploying/runtime-store.md | 6 +- docs/core/deploying/single-file/overview.md | 10 +- .../deploy-with-vs/csharp/deploy.csproj | 9 - .../csharp/deployment-example.cs | 35 -- .../snippets/deploy-with-vs/vb/deploy.vbproj | 9 - .../deploy-with-vs/vb/deployment-example.vb | 30 - .../deploy-with-vs/xml/access-by-line.txt | 1 - .../deploy-with-vs/xml/invariant.csproj | 12 - .../deploying/trimming/trim-self-contained.md | 10 +- docs/core/docker/build-container.md | 2 +- .../core/install/macos-notarization-issues.md | 2 +- .../expose-components-to-com.md | 2 +- docs/core/project-sdk/msbuild-props.md | 6 +- docs/core/rid-catalog.md | 2 +- .../troubleshoot-app-launch.md | 4 +- docs/core/tools/dotnet-clean.md | 2 +- docs/core/tools/dotnet-publish.md | 15 +- docs/core/tools/sdk-errors/netsdk1071.md | 2 +- docs/core/tools/troubleshoot-usage-issues.md | 2 +- .../publishing-with-visual-studio-code.md | 7 +- .../publishing-with-visual-studio.md | 9 +- docs/core/versions/selection.md | 4 +- docs/core/whats-new/dotnet-9/runtime.md | 2 +- docs/core/whats-new/dotnet-core-2-2.md | 2 +- docs/core/whats-new/dotnet-core-3-0.md | 6 +- docs/core/whats-new/dotnet-core-3-1.md | 2 +- docs/navigate/devops-testing/toc.yml | 6 +- docs/navigate/tools-diagnostics/index.yml | 2 +- docs/standard/glossary.md | 6 +- docs/standard/runtime-libraries-overview.md | 2 +- 43 files changed, 507 insertions(+), 746 deletions(-) delete mode 100644 docs/core/deploying/deploy-with-cli.md delete mode 100644 docs/core/deploying/deploy-with-vs.md create mode 100644 docs/core/deploying/includes/cli-c-release.md create mode 100644 docs/core/deploying/includes/cli-r-rid-optional.md create mode 100644 docs/core/deploying/includes/cli-r-rid.md delete mode 100644 docs/core/deploying/snippets/deploy-with-vs/csharp/deploy.csproj delete mode 100644 docs/core/deploying/snippets/deploy-with-vs/csharp/deployment-example.cs delete mode 100644 docs/core/deploying/snippets/deploy-with-vs/vb/deploy.vbproj delete mode 100644 docs/core/deploying/snippets/deploy-with-vs/vb/deployment-example.vb delete mode 100644 docs/core/deploying/snippets/deploy-with-vs/xml/access-by-line.txt delete mode 100644 docs/core/deploying/snippets/deploy-with-vs/xml/invariant.csproj diff --git a/.openpublishing.redirection.core.json b/.openpublishing.redirection.core.json index 12fa2129d8801..0d7c6c2bb6c3a 100644 --- a/.openpublishing.redirection.core.json +++ b/.openpublishing.redirection.core.json @@ -386,6 +386,14 @@ "source_path_from_root": "/docs/core/deploying/applications.md", "redirect_url": "/dotnet/core/deploying/index" }, + { + "source_path_from_root": "/docs/core/deploying/deploy-with-cli.md", + "redirect_url": "/dotnet/core/deploying/index" + }, + { + "source_path_from_root": "/docs/core/deploying/deploy-with-vs.md", + "redirect_url": "/dotnet/core/deploying/index" + }, { "source_path_from_root": "/docs/core/deploying/fixing-warnings.md", "redirect_url": "/dotnet/core/deploying/trimming/fixing-warnings", diff --git a/docs/architecture/microservices/multi-container-microservice-net-applications/multi-container-applications-docker-compose.md b/docs/architecture/microservices/multi-container-microservice-net-applications/multi-container-applications-docker-compose.md index 4498df493267f..86308780fc78e 100644 --- a/docs/architecture/microservices/multi-container-microservice-net-applications/multi-container-applications-docker-compose.md +++ b/docs/architecture/microservices/multi-container-microservice-net-applications/multi-container-applications-docker-compose.md @@ -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#publish-self-contained) +- **runtime-deps**: for production scenarios of [self-contained applications](../../../core/deploying/index.md#self-contained-deployment) For faster startup, runtime images also automatically set aspnetcore\_urls to port 80 and use Ngen to create a native image cache of assemblies. diff --git a/docs/core/compatibility/sdk/6.0/apphost-generated-for-macos.md b/docs/core/compatibility/sdk/6.0/apphost-generated-for-macos.md index 59f552bfacec7..96ec415ad532d 100644 --- a/docs/core/compatibility/sdk/6.0/apphost-generated-for-macos.md +++ b/docs/core/compatibility/sdk/6.0/apphost-generated-for-macos.md @@ -5,7 +5,7 @@ ms.date: 07/13/2021 --- # Generate apphost for macOS -When building on macOS, the .NET SDK now [produces an executable](../../../deploying/index.md#produce-an-executable) for app projects. +When building on macOS, the .NET SDK now produces an executable for app projects. Since .NET Core 3.0, the .NET SDK has created an executable for app projects when building on non-macOS operating systems. However, it did not create an executable on macOS since we weren't signing this binary. That resulted in an app that was recognized as dangerous by the OS, which made it hard for the user to run it. The .NET 6 SDK can sign the app executable, so it now produces the executable by default. diff --git a/docs/core/compatibility/sdk/8.0/arch-option.md b/docs/core/compatibility/sdk/8.0/arch-option.md index 77bd6f6d00969..a67d780d6889a 100644 --- a/docs/core/compatibility/sdk/8.0/arch-option.md +++ b/docs/core/compatibility/sdk/8.0/arch-option.md @@ -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#publish-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. +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. ## Previous behavior diff --git a/docs/core/compatibility/sdk/8.0/runtimespecific-app-default.md b/docs/core/compatibility/sdk/8.0/runtimespecific-app-default.md index 85d372f4b8217..4723b5916daaa 100644 --- a/docs/core/compatibility/sdk/8.0/runtimespecific-app-default.md +++ b/docs/core/compatibility/sdk/8.0/runtimespecific-app-default.md @@ -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#publish-self-contained) by default. Instead, they are [framework-dependent](../../../deploying/index.md#publish-framework-dependent) by default. +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. This is a breaking change in the following situations: diff --git a/docs/core/deploying/deploy-with-cli.md b/docs/core/deploying/deploy-with-cli.md deleted file mode 100644 index d7cc3a234dd4f..0000000000000 --- a/docs/core/deploying/deploy-with-cli.md +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: Publish apps with the .NET CLI -description: Learn to publish a .NET application using the .NET CLI commands. -author: adegeo -ms.author: adegeo -ms.date: 11/22/2024 -ms.custom: updateeachrelease -dev_langs: - - "csharp" - - "vb" ---- - -# Publish .NET apps with the .NET CLI - -This article demonstrates how you can publish your .NET application from the command line. .NET provides three ways to publish your applications. Framework-dependent deployment produces a cross-platform .dll file that uses the locally installed .NET runtime. Framework-dependent executable produces a platform-specific executable that uses the locally installed .NET runtime. Self-contained executable produces a platform-specific executable and includes a local copy of the .NET runtime. - -For an overview of these publishing modes, see [.NET Application Deployment](index.md). - -Looking for some quick help on using the CLI? The following table shows some examples of how to publish your app. You can specify the target framework with the `-f ` parameter or by editing the project file. For more information, see [Publishing basics](#publishing-basics). - -| Publish Mode | Command | -|-------------------------------------------------------------------|--------------------------------------------------------------------------------------------| -| [Framework-dependent deployment](#framework-dependent-deployment) | `dotnet publish -c Release -p:UseAppHost=false` | -| [Framework-dependent executable](#framework-dependent-executable) | `dotnet publish -c Release -r --self-contained false`
`dotnet publish -c Release` | -| [Self-contained deployment](#self-contained-deployment) | `dotnet publish -c Release -r --self-contained true` | - -> [!NOTE] -> -> - The `-c Release` parameter isn't required. It's provided as a reminder to publish the **Release** build of your app. -> - In **.NET SDK 3.1** or higher, framework-dependent executable is the default publishing mode when running the basic `dotnet publish` command. - -## Publishing basics - -The `` setting of the project file specifies the default target framework when you publish your app. You can change the target framework to any valid [Target Framework Moniker (TFM)](../../standard/frameworks.md). For example, if your project uses `net9.0`, a binary that targets .NET 9 is created. The TFM specified in this setting is the default target used by the [`dotnet publish`](../tools/dotnet-publish.md) command. - -If you want to target more than one framework, you can set the `` setting to multiple TFM values, separated by a semicolon. When you build your app, a build is produced for each target framework. However, when you publish your app, you must specify the target framework with the `dotnet publish -f ` command. - -The default **BUILD-CONFIGURATION** mode is **Release** unless changed with the `-c` parameter. - -The default output directory of the [`dotnet publish`](../tools/dotnet-publish.md) command is `./bin///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). - -### Native dependencies - -If your app has native dependencies, it may not run on a different operating system. For example, if your app uses the native Windows API, it won't run on macOS or Linux. You would need to provide platform-specific code and compile an executable for each platform. - -Consider also, if a library you referenced has a native dependency, your app may not run on every platform. However, it's possible a NuGet package you're referencing has included platform-specific versions to handle the required native dependencies for you. - -When distributing an app with native dependencies, you may need to use the `dotnet publish -r ` switch to specify the target platform you want to publish for. For a list of runtime identifiers, see [Runtime Identifier (RID) catalog](../rid-catalog.md). - -More information about platform-specific binaries is covered in the [Framework-dependent executable](#framework-dependent-executable) and [Self-contained deployment](#self-contained-deployment) sections. - -## Sample app - -You can use the following app to explore the publishing commands. The app is created by running the following commands in your terminal: - -```dotnetcli -mkdir apptest1 -cd apptest1 -dotnet new console -dotnet add package Figgle -``` - -The `Program.cs` or `Program.vb` file that is generated by the console template needs to be changed to the following: - -```csharp -using System; - -namespace apptest1 -{ - class Program - { - static void Main(string[] args) - { - Console.WriteLine(Figgle.FiggleFonts.Standard.Render("Hello, World!")); - } - } -} -``` - -```vb -Module Program - Sub Main(args As String()) - Console.WriteLine(Figgle.FiggleFonts.Standard.Render("Hello, World!")) - End Sub -End Module -``` - -When you run the app ([`dotnet run`](../tools/dotnet-run.md)), the following output is displayed: - -```terminal - _ _ _ _ __ __ _ _ _ - | | | | ___| | | ___ \ \ / /__ _ __| | __| | | - | |_| |/ _ \ | |/ _ \ \ \ /\ / / _ \| '__| |/ _` | | - | _ | __/ | | (_) | \ V V / (_) | | | | (_| |_| - |_| |_|\___|_|_|\___( ) \_/\_/ \___/|_| |_|\__,_(_) - |/ -``` - -## Framework-dependent deployment - -When you publish your app as an FDD, a `.dll` file is created in the `./bin///publish/` folder. To run your app, navigate to the output folder and use the `dotnet .dll` command. - -Your app is configured to target a specific version of .NET. That targeted .NET runtime is required to be on any machine where your app runs. For example, if your app targets .NET 9, any machine that your app runs on must have the .NET 9 runtime installed. As stated in the [Publishing basics](#publishing-basics) section, you can edit your project file to change the default target framework or to target more than one framework. - -Publishing an FDD creates an app that automatically rolls-forward to the latest .NET security patch available on the system that runs the app. For more information on version binding at compile time, see [Select the .NET version to use](../versions/selection.md#framework-dependent-apps-roll-forward). - -| Publish Mode | Command | -|--------------------------------|-------------------------------------------------------------| -| Framework-dependent deployment | `dotnet publish -c Release -p:UseAppHost=false` | - -## Framework-dependent executable - -Framework-dependent executable (FDE) is the default mode for the basic `dotnet publish` command. You don't need to specify any other parameters, as long as you want to target the current operating system. - -In this mode, a platform-specific executable host is created to host your cross-platform app. This mode is similar to FDD, as FDD requires a host in the form of the `dotnet` command. The host executable filename varies per platform and is named something similar to `.exe`. You can run this executable directly instead of calling `dotnet .dll`, which is still an acceptable way to run the app. - -Your app is configured to target a specific version of .NET. That targeted .NET runtime is required to be on any machine where your app runs. For example, if your app targets .NET 9, any machine that your app runs on must have the .NET 9 runtime installed. As stated in the [Publishing basics](#publishing-basics) section, you can edit your project file to change the default target framework or to target more than one framework. - -Publishing an FDE creates an app that automatically rolls-forward to the latest .NET security patch available on the system that runs the app. For more information on version binding at compile time, see [Select the .NET version to use](../versions/selection.md#framework-dependent-apps-roll-forward). - -| Publish Mode | Command | -|--------------------------------|-------------------------------------------------------------| -| Framework-dependent executable | `dotnet publish -c Release -r --self-contained false`
`dotnet publish -c Release` | - -Whenever you use the `-r` switch, the output folder path changes to: `./bin////publish/` - -If you use the [example app](#sample-app), run `dotnet publish -f net9.0 -r win-x64 --self-contained false`. This command creates the following executable: `./bin/Debug/net9.0/win-x64/publish/apptest1.exe` - -> [!NOTE] -> You can reduce the total size of your deployment by enabling **globalization invariant mode**. This mode is useful for applications that are not globally aware and that can use the formatting conventions, casing conventions, and string comparison and sort order of the [invariant culture](xref:System.Globalization.CultureInfo.InvariantCulture). For more information about **globalization invariant mode** and how to enable it, see [.NET Globalization Invariant Mode](https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-invariant-mode.md). - -### Configure .NET install search behavior - -In .NET 9 and later versions, you can configure the .NET installation search paths of the published executable via the [`AppHostDotNetSearch`](../project-sdk//msbuild-props.md#apphostdotnetsearch) and [`AppHostRelativeDotNet`](../project-sdk//msbuild-props.md#apphostrelativedotnet) properties. - -`AppHostDotNetSearch` allows specifying one or more locations where the executable will look for a .NET installation: - -- `AppLocal`: app executable's folder -- `AppRelative`: path relative to the app executable -- `EnvironmentVariable`: value of [`DOTNET_ROOT[_]`](../tools/dotnet-environment-variables.md#dotnet_root-dotnet_rootx86-dotnet_root_x86-dotnet_root_x64) environment variables -- `Global`: [registered](https://github.com/dotnet/designs/blob/main/accepted/2020/install-locations.md#global-install-to-custom-location) and [default](https://github.com/dotnet/designs/blob/main/accepted/2020/install-locations.md#global-install-to-default-location) global install locations - -`AppHostRelativeDotNet` specifies the path relative to the executable that will be searched when `AppHostDotNetSearch` contains `AppRelative`. - -For more information, see [`AppHostDotNetSearch`](../project-sdk//msbuild-props.md#apphostdotnetsearch), [`AppHostRelativeDotNet`](../project-sdk//msbuild-props.md#apphostrelativedotnet) and [install location options in apphost](https://github.com/dotnet/designs/blob/main/proposed/apphost-embed-install-location.md). - -## Self-contained deployment - -When you publish a self-contained deployment (SCD), the .NET SDK 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 (for example, for [.NET 8 on Linux](https://github.com/dotnet/core/blob/main/release-notes/8.0/linux-packages.md)). These dependencies must be present on the system 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). - -You must use the following switches with the `dotnet publish` command to publish an SCD: - -- `-r ` - - This switch uses an identifier (RID) to specify the target platform. For a list of runtime identifiers, see [Runtime Identifier (RID) catalog](../rid-catalog.md). - -- `--self-contained true` - - This switch tells the .NET SDK to create an executable as an SCD. - -| Publish Mode | Command | -|--------------------------------|-------------------------------------------------------------| -| Self-contained deployment | `dotnet publish -c Release -r --self-contained true` | - -> [!TIP] -> -> - In .NET 6 and later versions, you can reduce the total size of compatible self-contained apps by [publishing trimmed](trimming/trim-self-contained.md). This enables the trimmer to remove parts of the framework and referenced assemblies that are not on any code path or potentially referenced in [runtime reflection](../../csharp/advanced-topics/reflection-and-attributes/index.md). See [trimming incompatibilities](./trimming/incompatibilities.md) to determine if trimming makes sense for your application. -> - You can reduce the total size of your deployment by enabling **globalization invariant mode**. This mode is useful for applications that are not globally aware and that can use the formatting conventions, casing conventions, and string comparison and sort order of the [invariant culture](xref:System.Globalization.CultureInfo.InvariantCulture). For more information about **globalization invariant mode** and how to enable it, see [.NET Core Globalization Invariant Mode](https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-invariant-mode.md). - -## See also - -- [.NET Application Deployment Overview](index.md) -- [.NET Runtime IDentifier (RID) catalog](../rid-catalog.md) diff --git a/docs/core/deploying/deploy-with-vs.md b/docs/core/deploying/deploy-with-vs.md deleted file mode 100644 index 5e77c0f34cd73..0000000000000 --- a/docs/core/deploying/deploy-with-vs.md +++ /dev/null @@ -1,307 +0,0 @@ ---- -title: Deploy .NET Core apps with Visual Studio -description: Learn to deploy a .NET Core app with Visual Studio. -ms.date: 09/03/2018 -dev_langs: - - "csharp" - - "vb" -ms.custom: vs-dotnet ---- -# Deploy .NET Core apps with Visual Studio - -You can deploy a .NET Core application either as a *framework-dependent deployment*, which includes your application binaries but depends on the presence of .NET Core on the target system, or as a *self-contained deployment*, which includes both your application and .NET Core binaries. For an overview of .NET Core application deployment, see [.NET Core Application Deployment](index.md). - -The following sections show how to use Microsoft Visual Studio to create the following kinds of deployments: - -- Framework-dependent deployment -- Framework-dependent deployment with third-party dependencies -- Self-contained deployment -- Self-contained deployment with third-party dependencies - -For information on using Visual Studio to develop .NET Core applications, see [.NET Core dependencies and requirements](../install/windows.md). - -## Framework-dependent deployment - -Deploying a framework-dependent deployment with no third-party dependencies simply involves building, testing, and publishing the app. A simple example written in C# illustrates the process. - -1. Create the project. - - Select **File** > **New** > **Project**. In the **New Project** dialog, expand your language's (C# or Visual Basic) project categories in the **Installed** project types pane, choose **.NET Core**, and then select the **Console App (.NET Core)** template in the center pane. Enter a project name, such as "FDD", in the **Name** text box. Select the **OK** button. - -1. Add the application's source code. - - Open the *Program.cs* or *Program.vb* file in the editor and replace the autogenerated code with the following code. It prompts the user to enter text and displays the individual words entered by the user. It uses the regular expression `\w+` to separate the words in the input text. - - [!code-csharp[deployment#1](./snippets/deploy-with-vs/csharp/deployment-example.cs)] - [!code-vb[deployment#1](./snippets/deploy-with-vs/vb/deployment-example.vb)] - -1. Create a Debug build of your app. - - Select **Build** > **Build Solution**. You can also compile and run the Debug build of your application by selecting **Debug** > **Start Debugging**. - -1. Deploy your app. - - After you've debugged and tested the program, create the files to be deployed with your app. To publish from Visual Studio, do the following: - - 1. Change the solution configuration from **Debug** to **Release** on the toolbar to build a Release (rather than a Debug) version of your app. - - 1. Right-click on the project (not the solution) in **Solution Explorer** and select **Publish**. - - 1. In the **Publish** tab, select **Publish**. Visual Studio writes the files that comprise your application to the local file system. - - 1. The **Publish** tab now shows a single profile, **FolderProfile**. The profile's configuration settings are shown in the **Summary** section of the tab. - - The resulting files are placed in a directory named `Publish` on Windows and `publish` on Unix systems that is in a subdirectory of your project's *.\bin\release\netcoreapp2.1* subdirectory. - -Along with your application's files, the publishing process emits a program database (.pdb) file that contains debugging information about your app. The file is useful primarily for debugging exceptions. You can choose not to package it with your application's files. You should, however, save it in the event that you want to debug the Release build of your app. - -Deploy the complete set of application files in any way you like. For example, you can package them in a Zip file, use a simple `copy` command, or deploy them with any installation package of your choice. Once installed, users can then execute your application by using the `dotnet` command and providing the application filename, such as `dotnet fdd.dll`. - -In addition to the application binaries, your installer should also either bundle the shared framework installer or check for it as a prerequisite as part of the application installation. Installation of the shared framework requires Administrator/root access since it is machine-wide. - -## Framework-dependent deployment with third-party dependencies - -Deploying a framework-dependent deployment with one or more third-party dependencies requires that any dependencies be available to your project. The following additional steps are required before you can build your app: - -1. Use the **NuGet Package Manager** to add a reference to a NuGet package to your project; and if the package is not already available on your system, install it. To open the package manager, select **Tools** > **NuGet Package Manager** > **Manage NuGet Packages for Solution**. - -1. Confirm that your third-party dependencies (for example, `Newtonsoft.Json`) are installed on your system and, if they aren't, install them. The **Installed** tab lists NuGet packages installed on your system. If `Newtonsoft.Json` is not listed there, select the **Browse** tab and enter "Newtonsoft.Json" in the search box. Select `Newtonsoft.Json` and, in the right pane, select your project before selecting **Install**. - -1. If `Newtonsoft.Json` is already installed on your system, add it to your project by selecting your project in the right pane of the **Manage Packages for Solution** tab. - -A framework-dependent deployment with third-party dependencies is only as portable as its third-party dependencies. For example, if a third-party library only supports macOS, the app isn't portable to Windows systems. This happens if the third-party dependency itself depends on native code. A good example of this is [Kestrel server](/aspnet/core/fundamentals/servers/kestrel), which requires a native dependency on [libuv](https://github.com/libuv/libuv). When an FDD is created for an application with this kind of third-party dependency, the published output contains a folder for each [Runtime Identifier (RID)](../rid-catalog.md) that the native dependency supports (and that exists in its NuGet package). - -## Self-contained deployment without third-party dependencies - -Deploying a self-contained deployment with no third-party dependencies involves creating the project, modifying the *csproj* file, building, testing, and publishing the app. A simple example written in C# illustrates the process. You begin by creating, coding, and testing your project just as you would a framework-dependent deployment: - -1. Create the project. - - Select **File** > **New** > **Project**. In the **New Project** dialog, expand your language's (C# or Visual Basic) project categories in the **Installed** project types pane, choose **.NET Core**, and then select the **Console App (.NET Core)** template in the center pane. Enter a project name, such as "SCD", in the **Name** text box, and select the **OK** button. - -1. Add the application's source code. - - Open the *Program.cs* or *Program.vb* file in your editor, and replace the autogenerated code with the following code. It prompts the user to enter text and displays the individual words entered by the user. It uses the regular expression `\w+` to separate the words in the input text. - - [!code-csharp[deployment#1](./snippets/deploy-with-vs/csharp/deployment-example.cs)] - [!code-vb[deployment#1](./snippets/deploy-with-vs/vb/deployment-example.vb)] - -1. Determine whether you want to use globalization invariant mode. - - Particularly if your app targets Linux, you can reduce the total size of your deployment by taking advantage of [globalization invariant mode](https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-invariant-mode.md). Globalization invariant mode is useful for applications that are not globally aware and that can use the formatting conventions, casing conventions, and string comparison and sort order of the [invariant culture](xref:System.Globalization.CultureInfo.InvariantCulture). - - To enable invariant mode, right-click on your project (not the solution) in **Solution Explorer**, and select **Edit SCD.csproj** or **Edit SCD.vbproj**. Then add the following highlighted lines to the file: - - [!code-xml[globalization-invariant-mode](./snippets/deploy-with-vs/xml/invariant.csproj?highlight=7-9)] - -1. Create a Debug build of your application. - - Select **Build** > **Build Solution**. You can also compile and run the Debug build of your application by selecting **Debug** > **Start Debugging**. This debugging step lets you identify problems with your application when it's running on your host platform. You still will have to test it on each of your target platforms. - - If you've enabled globalization invariant mode, be particularly sure to test whether the absence of culture-sensitive data is suitable for your application. - -Once you've finished debugging, you can publish your self-contained deployment: - -# [Visual Studio 15.6 and earlier](#tab/vs156) - -After you've debugged and tested the program, create the files to be deployed with your app for each platform that it targets. - -To publish your app from Visual Studio, do the following: - -1. Define the platforms that your app will target. - - 1. Right-click on your project (not the solution) in **Solution Explorer** and select **Edit SCD.csproj**. - - 1. Create a `` tag in the `` section of your *csproj* file that defines the platforms your app targets, and specify the runtime identifier (RID) of each platform that you target. You also need to add a semicolon to separate the RIDs. See [Runtime identifier catalog](../rid-catalog.md) for a list of runtime identifiers. - - For example, the following example indicates that the app runs on 64-bit Windows operating systems and the 64-bit OS X operating system. - - ```xml - - win-x64;osx-x64 - - ``` - - The `` element can go into any `` that you have in your *csproj* file. A complete sample *csproj* file appears later in this section. - -1. Publish your app. - - After you've debugged and tested the program, create the files to be deployed with your app for each platform that it targets. - - To publish your app from Visual Studio, do the following: - - 1. Change the solution configuration from **Debug** to **Release** on the toolbar to build a Release (rather than a Debug) version of your app. - - 1. Right-click on the project (not the solution) in **Solution Explorer** and select **Publish**. - - 1. In the **Publish** tab, select **Publish**. Visual Studio writes the files that comprise your application to the local file system. - - 1. The **Publish** tab now shows a single profile, **FolderProfile**. The profile's configuration settings are shown in the **Summary** section of the tab. **Target Runtime** identifies which runtime has been published, and **Target Location** identifies where the files for the self-contained deployment were written. - - 1. Visual Studio by default writes all published files to a single directory. For convenience, it's best to create separate profiles for each target runtime and to place published files in a platform-specific directory. This involves creating a separate publishing profile for each target platform. So now rebuild the application for each platform by doing the following: - - 1. Select **Create new profile** in the **Publish** dialog. - - 1. In the **Pick a publish target** dialog, change the **Choose a folder** location to *bin\Release\PublishOutput\win-x64*. Select **OK**. - - 1. Select the new profile (**FolderProfile1**) in the list of profiles, and make sure that the **Target Runtime** is `win-x64`. If it isn't, select **Settings**. In the **Profile Settings** dialog, change the **Target Runtime** to `win-x64` and select **Save**. Otherwise, select **Cancel**. - - 1. Select **Publish** to publish your app for 64-bit Windows 10 platforms. - - 1. Follow the previous steps again to create a profile for the `osx-x64` platform. The **Target Location** is *bin\Release\PublishOutput\osx-x64*, and the **Target Runtime** is `osx-x64`. The name that Visual Studio assigns to this profile is **FolderProfile2**. - - Each target location contains the complete set of files (both your app files and all .NET Core files) needed to launch your app. - -Along with your application's files, the publishing process emits a program database (.pdb) file that contains debugging information about your app. The file is useful primarily for debugging exceptions. You can choose not to package it with your application's files. You should, however, save it in the event that you want to debug the Release build of your app. - -Deploy the published files in any way you like. For example, you can package them in a Zip file, use a simple `copy` command, or deploy them with any installation package of your choice. - -The following is the complete *csproj* file for this project. - -```xml - - - Exe - netcoreapp2.1 - win-x64;osx-x64 - - -``` - -# [Visual Studio 15.7 and later](#tab/vs157) - -After you've debugged and tested the program, create the files to be deployed with your app for each platform that it targets. This involves creating a separate profile for each target platform. - -For each platform that your application targets, do the following: - -1. Create a profile for your target platform. - - If this is the first profile you've created, right-click on the project (not the solution) in **Solution Explorer** and select **Publish**. - - If you've already created a profile, right-click on the project to open the **Publish** dialog if it isn't already open. Then select **New Profile**. - - The **Pick a Publish Target** dialog box opens. - -1. Select the location where Visual Studio publishes your application. - - If you're only publishing to a single platform, you can accept the default value in the **Choose a folder** text box; this publishes the framework-dependent deployment of your application to the *\\bin\Release\netcoreapp2.1\publish* directory. - - If you're publishing to more than one platform, append a string that identifies the target platform. For example, if you append the string "linux" to the file path, Visual Studio publishes the framework-dependent deployment of your application to the *\\bin\Release\netcoreapp2.1\publish\linux* directory. - -1. Create the profile by selecting the drop-down list icon next to the **Publish** button and selecting **Create Profile**. Then select the **Create Profile** button to create the profile. - -1. Indicate that you are publishing a self-contained deployment and define a platform that your app will target. - - 1. In the **Publish** dialog, select the **Configure** link to open the **Profile Settings** dialog. - - 1. Select **Self-contained** in the **Deployment Mode** list box. - - 1. In the **Target Runtime** list box, select one of the platforms that your application targets. - - 1. Select **Save** to accept your changes and close the dialog. - -1. Name your profile. - - 1. Select **Actions** > **Rename Profile** to name your profile. - - 2. Assign your profile a name that identifies the target platform, then select **Save*. - -Repeat these steps to define any additional target platforms that your application targets. - -You've configured your profiles and are now ready to publish your app. To do this: - - 1. If the **Publish** window isn't currently open, right-click on the project (not the solution) in **Solution Explorer** and select **Publish**. - - 2. Select the profile that you'd like to publish, then select **Publish**. Do this for each profile to be published. - - Each target location (in the case of our example, bin\release\netcoreapp2.1\publish\\*profile-name*) contains the complete set of files (both your app files and all .NET Core files) needed to launch your app. - -Along with your application's files, the publishing process emits a program database (.pdb) file that contains debugging information about your app. The file is useful primarily for debugging exceptions. You can choose not to package it with your application's files. You should, however, save it in the event that you want to debug the Release build of your app. - -Deploy the published files in any way you like. For example, you can package them in a Zip file, use a simple `copy` command, or deploy them with any installation package of your choice. - -The following is the complete *csproj* file for this project. - -```xml - - - Exe - netcoreapp2.1 - - -``` - -In addition, Visual Studio creates a separate publishing profile (\*.pubxml) for each platform that you target. For example, the file for our linux profile (linux.pubxml) appears as follows: - -```xml - - - - - FileSystem - Release - Any CPU - netcoreapp2.1 - bin\Release\netcoreapp2.1\publish\linux - win-x86 - true - <_IsPortable>false - - -``` - ---- - -## Self-contained deployment with third-party dependencies - -Deploying a self-contained deployment with one or more third-party dependencies involves adding the dependencies. The following additional steps are required before you can build your app: - -1. Use the **NuGet Package Manager** to add a reference to a NuGet package to your project; and if the package is not already available on your system, install it. To open the package manager, select **Tools** > **NuGet Package Manager** > **Manage NuGet Packages for Solution**. - -1. Confirm that your third-party dependencies (for example, `Newtonsoft.Json`) are installed on your system and, if they aren't, install them. The **Installed** tab lists NuGet packages installed on your system. If `Newtonsoft.Json` is not listed there, select the **Browse** tab and enter "Newtonsoft.Json" in the search box. Select `Newtonsoft.Json` and, in the right pane, select your project before selecting **Install**. - -1. If `Newtonsoft.Json` is already installed on your system, add it to your project by selecting your project in the right pane of the **Manage Packages for Solution** tab. - -The following is the complete *csproj* file for this project: - -# [Visual Studio 15.6 and earlier](#tab/vs156) - -```xml - - - Exe - netcoreapp2.1 - win-x64;osx-x64 - - - - - -``` - -# [Visual Studio 15.7 and later](#tab/vs157) - -```xml - - - Exe - netcoreapp2.1 - - - - - -``` - ---- - -When you deploy your application, any third-party dependencies used in your app are also contained with your application files. Third-party libraries aren't required on the system on which the app is running. - -You can only deploy a self-contained deployment with a third-party library to platforms supported by that library. This is similar to having third-party dependencies with native dependencies in your framework-dependent deployment, where the native dependencies won't exist on the target platform unless they were previously installed there. - -## See also - -- [.NET Core Application Deployment](index.md) -- [.NET Core Runtime Identifier (RID) catalog](../rid-catalog.md) diff --git a/docs/core/deploying/includes/cli-c-release.md b/docs/core/deploying/includes/cli-c-release.md new file mode 100644 index 0000000000000..4d80bb2cc0d9e --- /dev/null +++ b/docs/core/deploying/includes/cli-c-release.md @@ -0,0 +1,3 @@ +`-c Release` + +This switch sets the build configuration to Release, which is optimized for production deployment. diff --git a/docs/core/deploying/includes/cli-r-rid-optional.md b/docs/core/deploying/includes/cli-r-rid-optional.md new file mode 100644 index 0000000000000..6adcfa1157e8c --- /dev/null +++ b/docs/core/deploying/includes/cli-r-rid-optional.md @@ -0,0 +1,3 @@ +`-r ` (optional) + +This switch uses a runtime identifier (RID) to specify the target platform and ensures native dependencies are included (if required). For a list of runtime identifiers, see [Runtime Identifier (RID) catalog](../../rid-catalog.md). diff --git a/docs/core/deploying/includes/cli-r-rid.md b/docs/core/deploying/includes/cli-r-rid.md new file mode 100644 index 0000000000000..f14f6300ae168 --- /dev/null +++ b/docs/core/deploying/includes/cli-r-rid.md @@ -0,0 +1,3 @@ +`-r ` + +This switch uses a runtime identifier (RID) to specify the target platform and ensures native dependencies are included (if required). For a list of runtime identifiers, see [Runtime Identifier (RID) catalog](../../rid-catalog.md). diff --git a/docs/core/deploying/index.md b/docs/core/deploying/index.md index 076198a311ece..38f8e4620c0d8 100644 --- a/docs/core/deploying/index.md +++ b/docs/core/deploying/index.md @@ -1,185 +1,518 @@ --- -title: Application publishing +title: .NET application publishing overview description: Learn about the ways to publish a .NET application. .NET can publish platform-specific or cross-platform apps. You can publish an app as self-contained or as framework-dependent. Each mode affects how a user runs your app. -ms.date: 03/18/2024 +author: adegeo +ms.author: adegeo +ms.date: 08/11/2025 +ms.custom: updateeachrelease +ai-usage: ai-assisted +zone_pivot_groups: development-environment-one --- # .NET application publishing overview -Applications you create with .NET can be published in two different modes, and the mode affects how a user runs your app. +This article explains the different ways to publish a .NET application. It covers publishing modes, how to produce executables and cross-platform binaries, and the impact of each approach on deployment and runtime environments. You can publish .NET applications using either the .NET CLI or Visual Studio. -Publishing your app as *self-contained* produces an application that includes the .NET runtime and libraries, and your application and its dependencies. Users of the application can run it on a machine that doesn't have the .NET runtime installed. +::: zone pivot="vscode" -Publishing your app as *framework-dependent* produces an application that includes only your application itself and its dependencies. Users of the application have to separately install the .NET runtime. +For a short tutorial on publishing, see [Tutorial: Publish a .NET console application using Visual Studio Code](../tutorials/publishing-with-visual-studio-code.md). -Both publishing modes produce a platform-specific executable by default. Framework-dependent applications can be created without an executable, and these applications are cross-platform. +::: zone-end -When an executable is produced, you can specify the target platform with a runtime identifier (RID). For more information about RIDs, see [.NET RID Catalog](../rid-catalog.md). +::: zone pivot="visualstudio" -The following table outlines the commands used to publish an app as framework-dependent or self-contained: +For a short tutorial on publishing, see [Tutorial: Publish a .NET console application using Visual Studio](../tutorials/publishing-with-visual-studio.md). -| Type | Command | -|--|--| -| [framework-dependent executable](#publish-framework-dependent) for the current platform. | [`dotnet publish`](../tools/dotnet-publish.md) | -| [framework-dependent executable](#publish-framework-dependent) for a specific platform. | [`dotnet publish -r `](../tools/dotnet-publish.md) | -| [framework-dependent binary](#publish-framework-dependent). | [`dotnet publish`](../tools/dotnet-publish.md) | -| [self-contained executable](#publish-self-contained). | [`dotnet publish -r --self-contained`](../tools/dotnet-publish.md) | +::: zone-end -For more information, see [.NET dotnet publish command](../tools/dotnet-publish.md). +## What is publishing -## Produce an executable +Publishing a .NET app means compiling source code to create an executable or binary, along with its dependencies and related files, for distribution. After publishing, you deploy the app to a server, distribution platform, container, or cloud environment. The publishing process prepares an app for deployment and use outside of a development environment. -Executables aren't cross-platform, they're specific to an operating system and CPU architecture. When publishing your app and creating an executable, you can publish the app as [self-contained](#publish-self-contained) or [framework-dependent](#publish-framework-dependent). Publishing an app as self-contained includes the .NET runtime with the app, and users of the app don't have to worry about installing .NET before running the app. Publishing an app as framework-dependent doesn't include the .NET runtime; only the app and third-party dependencies are included. +## Publishing modes -The following commands produce an executable: +There are two primary ways to publish an app. Some factors that influence this decision include whether the deployment environment has the appropriate .NET Runtime installed and whether you need specific compilation features that require bundling the runtime with your app. The two publishing modes are: -| Type | Command | -|--|--| -| [framework-dependent executable](#publish-framework-dependent) for the current platform. | [`dotnet publish`](../tools/dotnet-publish.md) | -| [framework-dependent executable](#publish-framework-dependent) for a specific platform. | [`dotnet publish -r `](../tools/dotnet-publish.md) | -| [self-contained executable](#publish-self-contained). | [`dotnet publish -r --self-contained`](../tools/dotnet-publish.md) | +- **Publish self-contained**\ +This mode produces a publishing folder that includes a platform-specific executable used to start the app, a compiled binary containing app code, any app dependencies, and the .NET runtime required to run the app. The environment that runs the app doesn't need to have the .NET runtime preinstalled. + +- **Publish framework-dependent**\ +This mode produces a publishing folder that includes a platform-specific executable used to start the app, a compiled binary containing app code, and any app dependencies. The environment that runs the app must have a version of the .NET runtime installed that the app can use. An optional platform-specific executable can be produced. + +> [!IMPORTANT] +> You specify the target platform with a runtime identifier (RID). For more information about RIDs, see [.NET RID Catalog](../rid-catalog.md). + +## Publishing basics + +The [``](../project-sdk/msbuild-props.md#targetframework) setting of the project file specifies the default target framework when you publish your app. You can change the target framework to any valid [Target Framework Moniker (TFM)](../../standard/frameworks.md). For example, if your project uses `net9.0`, a binary that targets .NET 9 is created. + +If you want to target more than one framework, you can set the [``](../project-sdk/msbuild-props.md#targetframeworks) setting to multiple TFM values, separated by a semicolon. When you build your app, your app is built for each target framework defined by your project. However, when you publish your app, you must specify the target framework: + +::: zone pivot="cli,vscode" + +The default build configuration mode is **Release**, unless changed with the `-c` parameter. + +```dotnet +dotnet publish -c Release -f net9.0 +``` + +The default output directory of the [`dotnet publish`](../tools/dotnet-publish.md) command is `./bin///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). + +::: zone-end + +::: zone pivot="visualstudio" + +In Visual Studio, create separate publishing profiles for each target framework. + +::: zone-end + +### Portable binaries -## Produce a cross-platform binary +When you publish a .NET app, you can target a specific platform or create a portable binary. By default, even when creating a portable binary, .NET publishes a platform-specific executable alongside the portable DLL unless you explicitly disable this behavior. -Cross-platform binaries are created when you publish your app as [framework-dependent](#publish-framework-dependent), in the form of a *dll* file. The *dll* file is named after your project. For example, if you have an app named **word_reader**, a file named *word_reader.dll* is created. Apps published in this way are run with the `dotnet ` command and can be run on any platform. +The platform-specific executable is created because of the `UseAppHost` property, which defaults to `true`. To publish only the portable DLL without the platform-specific executable, set `UseAppHost` to `false` either on the command line (`-p:UseAppHost=false`) or as a [project property](../project-sdk/msbuild-props.md#useapphost). -Cross-platform binaries can be run on any operating system as long as the targeted .NET runtime is already installed. If the targeted .NET runtime isn't installed, the app may run using a newer runtime if the app is configured to roll-forward. For more information, see [framework-dependent apps roll forward](../versions/selection.md#framework-dependent-apps-roll-forward). +The benefit of targeting a specific platform is that it can handle [native dependencies](#native-dependencies) that your app might require, ensuring compatibility with the target platform's specific requirements. -You can choose to run the app as a platform-specific executable or as a cross-platform binary via `dotnet` command. There should be no app behavior difference when launching the platform-specific executable versus the `dotnet` command for ordinary server apps Launching via a platform-specific executable gives you better integration with the underlying OS. For example: +### Native dependencies -- You see the application executable name in your process list and not `dotnet`, which could be confusing if there's more than one. -- You can customize the platform-specific executable with OS specific features. For example, see [this discussion about configuring default stack size on Windows](https://github.com/dotnet/runtime/issues/96347#issuecomment-1981470713). +If your app has native dependencies, it might not run on a different operating system if published as a portable binary. For example, apps that depend on the Windows API don't natively run on macOS or Linux. You would need to provide platform-specific code and compile an executable for each platform. -The following command produces a cross-platform binary: +Consider also, if a library you referenced provides platform-specific dependencies, your app might not run on every platform. However, when you publish and target a specific platform, the platform-specific dependencies of a NuGet package are copied to the publish folder. -| Type | Command | +To ensure that your app is published with its native dependencies, publish for a specific platform: + +::: zone pivot="cli,vscode" + +```dotnetcli +dotnet publish -c Release -r +``` + +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] + +- [!INCLUDE [cli-r-rid](includes/cli-r-rid.md)] + +::: zone-end + +::: zone pivot="visualstudio" + +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. If this is your first time publishing, select **Folder** as the publish target and select **Next**. +01. Choose a folder location or accept the default, then select **Finish**. +01. In the publish profile, select **Show all settings**. +01. Set **Target Runtime** to your desired platform (for example, **win-x64** for 64-bit Windows). +01. Select **Save** and then **Publish**. + +::: zone-end + +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. + +| Publish Mode | Command | |--|--| -| [framework-dependent cross-platform binary](#publish-framework-dependent). | [`dotnet publish`](../tools/dotnet-publish.md) | +| [Framework-dependent deployment](#framework-dependent-deployment) | `dotnet publish -c Release [-r ]` | +| [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 ] --self-contained true` | +| [Single-file deployment](#single-file-deployment) | `dotnet publish -c Release [-r ] -p:PublishSingleFile=true` | +| [Native AOT deployment](#native-aot-deployment) | `dotnet publish -c Release [-r ] -p:PublishAot=true` | +| [ReadyToRun deployment](#readytorun-deployment) | `dotnet publish -c Release [-r ] -p:PublishReadyToRun=true` | +| [Container deployment](#container-deployment) | `dotnet publish -c Release [-r ] -t:PublishContainer` | + +::: zone-end + +## Framework-dependent deployment + +Framework-dependent deployment is the default mode when you publish from either the CLI or Visual Studio. In this mode, a platform-specific executable host is created to host your cross-platform app. The host executable filename varies per platform and is named something similar to `.exe`. You can run this executable directly instead of calling `dotnet .dll`, which is still an acceptable way to run the app. + +Your app is configured to target a specific version of .NET. That targeted .NET runtime is required to be on the environment where your app runs. For example, if your app targets .NET 9, any environment that your app runs on must have the .NET 9 runtime installed. + +Publishing a framework-dependent deployment creates an app that automatically rolls forward to the latest .NET security patch available on the environment that runs the app. 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** + +- **Small deployment**: Only the app and its dependencies are distributed. The environment where the app is run must already have the .NET runtime installed. +- **Cross-platform**: The app and any .NET-based library runs on other operating systems. +- **Uses the latest patched runtime**: The app uses the latest runtime installed in the environment. + +**Disadvantages** + +- **Requires pre-installing the runtime**: The app can run only if the version of .NET it targets is already installed in the environment. +- **.NET might change**: The environment where the app is run might use a newer .NET runtime, which could change app behavior. + +### Publish + +::: zone pivot="cli,vscode" + +```dotnetcli +dotnet publish -c Release [-r ] +``` + +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] + +- [!INCLUDE [cli-r-rid](includes/cli-r-rid.md)] + +Or explicitly: + +```dotnetcli +dotnet publish -c Release [-r ] --self-contained false +``` + +- `--self-contained false` + + This switch explicitly tells the .NET SDK to create a framework-dependent deployment. + +::: zone-end + +::: zone pivot="visualstudio" + +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. If this is your first time publishing, select **Folder** as the publish target and select **Next**. +01. Choose a folder location or accept the default, then select **Finish**. +01. In the publish profile, select **Show all settings**. +01. Set **Deployment Mode** to **Framework-dependent** (this is the default). +01. Set **Target Runtime** to your desired platform (for example, **win-x64** for 64-bit Windows). +01. Select **Save** and then **Publish**. + +::: zone-end + +### Configure .NET install search behavior + +In .NET 9 and later versions, you can configure the .NET installation search paths of the published executable via the [`AppHostDotNetSearch`](../project-sdk//msbuild-props.md#apphostdotnetsearch) and [`AppHostRelativeDotNet`](../project-sdk//msbuild-props.md#apphostrelativedotnet) properties. + +`AppHostDotNetSearch` allows specifying one or more locations where the executable will look for a .NET installation: + +- `AppLocal`: app executable's folder +- `AppRelative`: path relative to the app executable +- `EnvironmentVariable`: value of [`DOTNET_ROOT[_]`](../tools/dotnet-environment-variables.md#dotnet_root-dotnet_rootx86-dotnet_root_x86-dotnet_root_x64) environment variables +- `Global`: [registered](https://github.com/dotnet/designs/blob/main/accepted/2020/install-locations.md#global-install-to-custom-location) and [default](https://github.com/dotnet/designs/blob/main/accepted/2020/install-locations.md#global-install-to-default-location) global install locations + +`AppHostRelativeDotNet` specifies the path relative to the executable that will be searched when `AppHostDotNetSearch` contains `AppRelative`. + +For more information, see [`AppHostDotNetSearch`](../project-sdk//msbuild-props.md#apphostdotnetsearch), [`AppHostRelativeDotNet`](../project-sdk//msbuild-props.md#apphostrelativedotnet), and [install location options in apphost](https://github.com/dotnet/designs/blob/main/proposed/apphost-embed-install-location.md). + +### Cross-platform DLL deployment + +Alternatively, you can publish your app as a cross-platform DLL without a platform-specific executable. In this mode, a `.dll` file is created in the publish output folder. To run your app, navigate to the output folder and use the `dotnet .dll` command. + +To publish as a cross-platform DLL: -## Publish framework-dependent +::: zone pivot="cli,vscode" -Apps published as framework-dependent are cross-platform and don't include the .NET runtime. The user of your app is required to install the .NET runtime. +```dotnetcli +dotnet publish -c Release -p:UseAppHost=false +``` + +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] -Publishing an app as framework-dependent produces a [cross-platform binary](#produce-a-cross-platform-binary) as a *dll* file, and a [platform-specific executable](#produce-an-executable) that targets your current platform. The *dll* is cross-platform while the executable isn't. For example, if you publish an app named **word_reader** and target Windows, a *word_reader.exe* executable is created along with *word_reader.dll*. When targeting Linux or macOS, a *word_reader* executable is created along with *word_reader.dll*. If the app uses a NuGet package that has platform-specific implementations, dependencies for all platforms are copied to the *publish\\runtimes\\{platform}* folder. +- `-p:UseAppHost=false` -The cross-platform binary of your app can be run with the `dotnet ` command, and can be run on any platform. + This property disables the creation of a platform-specific executable, producing only the portable DLL. -### Platform-specific and framework-dependent +::: zone-end -You can publish a framework-dependent app that's platform-specific by passing the `-r ` parameters to the [`dotnet publish`](../tools/dotnet-publish.md) command. Publishing in this way is the same as [publish framework-dependent](#publish-framework-dependent), except that platform-specific dependencies are handled differently. If the app uses a NuGet package that has platform-specific implementations, only the targeted platform's dependencies are copied. These dependencies are copied directly to the *publish* folder. +::: zone pivot="visualstudio" -While technically the binary produced is cross-platform, by targeting a specific platform, your app isn't guaranteed to run cross-platform. You can run `dotnet `, but the app may crash when it tries to access platform-specific dependencies that are missing. +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. If this is your first time publishing, select **Folder** as the publish target and select **Next**. +01. Choose a folder location or accept the default, then select **Finish**. +01. In the publish profile, select **Show all settings**. +01. Set **Deployment Mode** to **Framework-dependent**. +01. Uncheck **Produce single file**. +01. Set **Target Runtime** to **Portable** (or leave blank). +01. Select **Save** and then **Publish**. -For more information about RIDs, see [.NET RID Catalog](../rid-catalog.md). +::: zone-end -### Advantages +## Self-contained deployment -- **Small deployment**\ -Only your app and its dependencies are distributed. The .NET runtime and libraries are installed by the user and all apps share the runtime. +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. -- **Cross-platform**\ -Your app and any .NET-based library runs on other operating systems. You don't need to define a target platform for your app. For information about the .NET file format, see [.NET Assembly File Format](../../standard/assembly/file-format.md). +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). -- **Uses the latest patched runtime**\ -The app uses the latest runtime (within the targeted major-minor family of .NET) installed on the target system. This means your app automatically uses the latest patched version of the .NET runtime. This default behavior can be overridden. For more information, see [framework-dependent apps roll forward](../versions/selection.md#framework-dependent-apps-roll-forward). +**Advantages** -### Disadvantages +- **Control .NET version**: Control which version of .NET is deployed with the app. +- **Platform-specific targeting**: Because the app must be published for each platform, it's clear where the app runs. -- **Requires pre-installing the runtime**\ -Your app can run only if the version of .NET your app targets is already installed on the host system. You can configure roll-forward behavior for the app to either require a specific version of .NET or allow a newer version of .NET. For more information, see [framework-dependent apps roll forward](../versions/selection.md#framework-dependent-apps-roll-forward). +**Disadvantages** -- **.NET may change**\ -It's possible for the .NET runtime and libraries to be updated on the machine where the app is run. In rare cases, this may change the behavior of your app if you use the .NET libraries, which most apps do. You can configure how your app uses newer versions of .NET. For more information, see [framework-dependent apps roll forward](../versions/selection.md#framework-dependent-apps-roll-forward). +- **Larger deployments**: Because the app includes the .NET runtime and all dependencies, the download size and hard drive space required is greater than a **framework-dependent deployment**. +- **Harder to update the .NET version**: The .NET Runtime can only be upgraded by releasing a new version of the app. -### Examples +> [!TIP] +> You can reduce the total size of compatible self-contained apps by [publishing trimmed](trimming/trim-self-contained.md) or by enabling **globalization invariant mode**. For more information about globalization invariant mode, see [.NET Globalization Invariant Mode](https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-invariant-mode.md). -Publish an app as cross-platform and framework-dependent. An executable that targets your current platform is created along with the *dll* file. Any platform-specific dependencies are published with the app. +### Publish + +::: zone pivot="cli,vscode" ```dotnetcli -dotnet publish +dotnet publish -c Release -r --self-contained true ``` -Publish an app as platform-specific and framework-dependent. A Linux 64-bit executable is created along with the *dll* file. Only the targeted platform's dependencies are published with the app. +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] + +- [!INCLUDE [cli-r-rid](includes/cli-r-rid.md)] + +- `--self-contained true` + + This switch tells the .NET SDK to create an executable as a self-contained deployment (SCD). + +::: zone-end + +::: zone pivot="visualstudio" + +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. If this is your first time publishing, select **Folder** as the publish target and select **Next**. +01. Choose a folder location or accept the default, then select **Finish**. +01. In the publish profile, select **Show all settings**. +01. Set **Deployment Mode** to **Self-contained**. +01. Set **Target Runtime** to your desired platform (for example, **win-x64** for 64-bit Windows). +01. Select **Save** and then **Publish**. + +::: zone-end + +## Single-file deployment + +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. + +Single-file apps are always OS and architecture specific. You need to publish for each configuration, such as Linux x64, Linux Arm64, Windows x64, and so forth. + +**Advantages** + +- **Simplified distribution**: Deploy and distribute your application as a single executable file. +- **Reduced file clutter**: All dependencies are bundled, eliminating the need to manage multiple files. +- **Easy deployment**: Copy a single file to deploy the application. + +**Disadvantages** + +- **Larger file size**: The single file includes all dependencies, making it larger than individual files. +- **Slower startup**: Files must be extracted at run time, 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. + +For more information about single-file deployment, see [Single-file deployment](single-file/overview.md). + +### Publish + +::: zone pivot="cli,vscode" ```dotnetcli -dotnet publish -r linux-x64 +dotnet publish -c Release -r -p:PublishSingleFile=true ``` -## Publish self-contained +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] -Publishing your app as self-contained produces a platform-specific executable. The output publishing folder contains all components of the app, including the .NET libraries and target runtime. The app is isolated from other .NET apps and doesn't use a locally installed shared runtime. The user of your app isn't required to download and install .NET. +- [!INCLUDE [cli-r-rid](includes/cli-r-rid.md)] -You can publish a self-contained app by passing the `--self-contained` parameter to the [`dotnet publish`](../tools/dotnet-publish.md) command. The executable binary is produced for the specified target platform. For example, if you have an app named **word_reader**, and you publish a self-contained executable for Windows, a *word_reader.exe* file is created. Publishing for Linux or macOS, a *word_reader* file is created. The target platform and architecture is specified with the `-r ` parameter for the [`dotnet publish`](../tools/dotnet-publish.md) command. For more information about RIDs, see [.NET RID Catalog](../rid-catalog.md). +- `-p:PublishSingleFile=true` -If the app has platform-specific dependencies, such as a NuGet package containing platform-specific dependencies, these are copied to the publish folder along with the app. + This property bundles all application-dependent files into a single binary. -### Advantages +::: zone-end -- **Control .NET version**\ -You control which version of .NET is deployed with your app. +::: zone pivot="visualstudio" -- **Platform-specific targeting**\ -Because you have to publish your app for each platform, you know where your app runs. If .NET introduces a new platform, users can't run your app on that platform until you release a version targeting that platform. You can test your app for compatibility problems before your users run your app on the new platform. +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. If this is your first time publishing, select **Folder** as the publish target and select **Next**. +01. Choose a folder location or accept the default, then select **Finish**. +01. In the publish profile, select **Show all settings**. +01. Set **Deployment Mode** to **Self-contained** or **Framework-dependent**. +01. Set **Target Runtime** to your desired platform (for example, **win-x64** for 64-bit Windows). +01. Check **Produce single file**. +01. Select **Save** and then **Publish**. -### Disadvantages +::: zone-end -- **Larger deployments**\ -Because your app includes the .NET runtime and all of your app dependencies, the download size and hard drive space required is greater than a [framework-dependent](#publish-framework-dependent) version. +## Native AOT deployment - > [!TIP] - > You can reduce the size of your deployment on Linux systems by approximately 28 MB by using .NET [*globalization invariant mode*](https://github.com/dotnet/runtime/blob/main/docs/design/features/globalization-invariant-mode.md). This forces your app to treat all cultures like the [invariant culture](xref:System.Globalization.CultureInfo.InvariantCulture?displayProperty=nameWithType). +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. - > [!TIP] - > [IL trimming](trimming/trim-self-contained.md) can further reduce the size of your deployment. +**Advantages** -- **Harder to update the .NET version**\ -.NET Runtime (distributed with your app) can only be upgraded by releasing a new version of your app. +- **Fast startup**: No JIT compilation needed at run time, leading to faster application startup. +- **Reduced memory usage**: Lower memory footprint compared to traditional .NET applications. +- **No runtime dependency**: The application runs without requiring .NET runtime installation. +- **Smaller deployment size**: Often smaller than **self-contained deployment** with the full runtime. -### Examples +**Disadvantages** -Publish an app self-contained. A macOS 64-bit executable is created. +- **Limited framework support**: Not all .NET features and libraries are compatible with Native AOT. +- **Longer build times**: Compilation to native code takes longer than regular builds. +- **Platform-specific**: Must compile separately for each target platform and architecture. +- **Debugging limitations**: More complex debugging experience compared to regular .NET applications. + +For more information about Native AOT deployment, see [Native AOT deployment](native-aot/index.md). + +### Publish + +::: zone pivot="cli,vscode" ```dotnetcli -dotnet publish -r osx-x64 --self-contained +dotnet publish -c Release -r -p:PublishAot=true ``` -Publish an app self-contained. A Windows 64-bit executable is created. +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] + +- [!INCLUDE [cli-r-rid](includes/cli-r-rid.md)] + +- `-p:PublishAot=true` + + This property enables Native AOT compilation, which compiles the app directly to native code. + +::: zone-end + +::: zone pivot="visualstudio" + +Native AOT publishing must be configured in the project file. You can't enable it through the Visual Studio publishing UI. + +01. In **Solution Explorer**, right-click on your project and select **Edit Project File**. +01. Add the following property to a ``: + + ```xml + true + ``` + +01. Save the project file. +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. If this is your first time publishing, select **Folder** as the publish target and select **Next**. +01. Choose a folder location or accept the default, then select **Finish**. +01. In the publish profile, select **Show all settings**. +01. Set **Deployment Mode** to **Self-contained**. +01. Set **Target Runtime** to your desired platform (for example, **win-x64** for 64-bit Windows). +01. Select **Save** and then **Publish**. + +For more information about Native AOT deployment, see [Native AOT deployment](native-aot/index.md). + +::: zone-end + +## ReadyToRun deployment + +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. + +ReadyToRun binaries contain both intermediate language (IL) code and the native version of the same code. While R2R binaries are larger than regular assemblies, they provide better startup performance. + +**Advantages** + +- **Improved startup time**: The app spends less time running the JIT compiler during startup. +- **Better first-use performance**: Reduced latency for first-time execution of code paths. +- **Compatible with existing code**: Works with most .NET libraries and frameworks without modification. +- **Flexible deployment**: Can be combined with both **framework-dependent deployment** and **self-contained deployment** modes. + +**Disadvantages** + +- **Larger size**: The app is larger on disk due to including both IL and native code. +- **Longer build times**: Compilation takes more time than standard publishing. +- **Platform-specific optimizations**: Best performance gains require targeting specific platforms. + +### Publish + +::: zone pivot="cli,vscode" ```dotnetcli -dotnet publish -r win-x64 --self-contained +dotnet publish -c Release -r -p:PublishReadyToRun=true ``` -## Publish with ReadyToRun images +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] + +- [!INCLUDE [cli-r-rid](includes/cli-r-rid.md)] + +- `-p:PublishReadyToRun=true` + + This property enables ReadyToRun compilation, which improves startup performance by pre-compiling assemblies. + +::: zone-end + +::: zone pivot="visualstudio" + +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. If this is your first time publishing, select **Folder** as the publish target and select **Next**. +01. Choose a folder location or accept the default, then select **Finish**. +01. In the publish profile, select **Show all settings**. +01. Set **Deployment Mode** to **Self-contained** or **Framework-dependent**. +01. Set **Target Runtime** to your desired platform (for example, **win-x64** for 64-bit Windows). +01. Check **Enable ReadyToRun compilation**. +01. Select **Save** and then **Publish**. -Publishing with ReadyToRun images improves the startup time of your application at the cost of increasing the size of your application. For more information, see [ReadyToRun](ready-to-run.md). +::: zone-end -### Advantages +For more information about ReadyToRun deployment, see [ReadyToRun compilation](ready-to-run.md). -- **Improved startup time**\ -The application spends less time running the JIT. +## Container deployment -### Disadvantages +When you publish your app as a container, the .NET SDK packages your application and its dependencies into a container image without requiring a separate Dockerfile. This deployment mode creates a complete container image that can be run on any container runtime, such as Docker or Podman. Container deployment simplifies the containerization process by eliminating the need to write and maintain Dockerfiles while providing optimized base images. -- **Larger size**\ -The application is larger on disk. +Starting with .NET SDK 8.0.200, container support is included by default and doesn't require extra NuGet packages. For console applications, you might need to enable container support explicitly by setting the `EnableSdkContainerSupport` property to `true`. -### Examples +> [!TIP] +> For more information about project settings related to containers, see [Containerize a .NET app reference](../containers/publish-configuration.md). -Publish an app self-contained and ReadyToRun. A macOS 64-bit executable is created. +**Advantages** + +- **Simplified containerization**: No need to write or maintain Dockerfiles for basic scenarios. +- **Optimized base images**: Uses Microsoft-provided, optimized base images with the latest security updates. +- **Consistent environment**: Ensures consistent runtime environment across development, testing, and production. +- **Easy distribution**: Container images can be easily shared and deployed across different environments. +- **Platform isolation**: Applications run in isolated containers, reducing conflicts between applications. + +**Disadvantages** + +- **Container runtime dependency**: The target environment must have a container runtime installed. +- **Image size**: Container images are typically larger than other deployment methods. +- **Learning curve**: Requires understanding of container concepts and tooling. +- **Limited customization**: Less flexibility compared to custom Dockerfiles for complex scenarios. + +### Publish + +::: zone pivot="cli,vscode" ```dotnetcli -dotnet publish -c Release -r osx-x64 --self-contained -p:PublishReadyToRun=true +dotnet publish -c Release [-r ] /t:PublishContainer ``` -Publish an app self-contained and ReadyToRun. A Windows 64-bit executable is created. +- [!INCLUDE [cli-c-release](includes/cli-c-release.md)] + +- [!INCLUDE [cli-r-rid](includes/cli-r-rid.md)] + +- `-t:PublishContainer` + + This target publishes the application as a container image. + +You can also use the publish profile approach: ```dotnetcli -dotnet publish -c Release -r win-x64 --self-contained -p:PublishReadyToRun=true +dotnet publish -c Release [-r ] -p:PublishProfile=DefaultContainer ``` +- `-p:PublishProfile=DefaultContainer` + + This profile triggers the container publishing process. + +::: zone-end + +::: zone pivot="visualstudio" + +01. Right-click on the project in **Solution Explorer** and select **Publish**. +01. Select **Container Registry** as the publish target and select **Next**. +01. Choose your target container registry (such as **Azure Container Registry**, **Docker Hub**, or **Generic Registry**) and select **Next**. +01. Configure the registry connection details and authentication. +01. In the publish profile, select **Show all settings**. +01. Set **Deployment Mode** to **Self-contained** or **Framework-dependent** based on your needs. +01. Set **Target Runtime** to your desired platform (for example, **linux-x64** for Linux containers). +01. Configure container-specific settings like image name and tags. +01. Select **Save** and then **Publish**. + +::: zone-end + +For more information about container deployment, see [.NET SDK container creation overview](../containers/overview.md). + ## See also -- [Deploying .NET Apps with .NET CLI.](deploy-with-cli.md) -- [Deploying .NET Apps with Visual Studio.](deploy-with-vs.md) -- [.NET Runtime Identifier (RID) catalog.](../rid-catalog.md) -- [Select the .NET version to use.](../versions/selection.md) +- [.NET Runtime Identifier (RID) catalog](../rid-catalog.md) +- [Select the .NET version to use](../versions/selection.md) diff --git a/docs/core/deploying/native-aot/index.md b/docs/core/deploying/native-aot/index.md index 8245269150b97..79c5b2c77edf0 100644 --- a/docs/core/deploying/native-aot/index.md +++ b/docs/core/deploying/native-aot/index.md @@ -7,11 +7,11 @@ ms.date: 06/12/2023 # Native AOT deployment -Publishing your app as *Native AOT* produces an app that's [self-contained](../index.md#publish-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. +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. 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#publish-self-contained). +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). ## Prerequisites @@ -132,7 +132,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#publish-self-contained), increasing their size as compared to framework-dependent apps). +- Apps include required runtime libraries (just like [self-contained apps](../index.md#self-contained-deployment), increasing their size as compared to framework-dependent apps). - always use their interpreted form, which is slower than run-time generated compiled code. - Generic parameters substituted with struct type arguments will 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. diff --git a/docs/core/deploying/ready-to-run.md b/docs/core/deploying/ready-to-run.md index 6e10c03466dad..c0e4f653f53b8 100644 --- a/docs/core/deploying/ready-to-run.md +++ b/docs/core/deploying/ready-to-run.md @@ -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#publish-self-contained) deployment. To enable composite ReadyToRun compilation, specify the `` 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#self-contained-deployment) deployment. To enable composite ReadyToRun compilation, specify the `` property. ```xml @@ -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#publish-self-contained) deployment. +> In .NET 6, Composite ReadyToRun is only supported for [self-contained](index.md#self-contained-deployment) deployment. ## Cross platform/architecture restrictions diff --git a/docs/core/deploying/runtime-store.md b/docs/core/deploying/runtime-store.md index da0738b770650..99cace43004fd 100644 --- a/docs/core/deploying/runtime-store.md +++ b/docs/core/deploying/runtime-store.md @@ -122,11 +122,11 @@ Specify the target manifests in the project file only when the target environmen The ASP.NET Core implicit store applies only to ASP.NET Core 2.0. We strongly recommend applications use ASP.NET Core 2.1 and later, which does **not** use the implicit store. ASP.NET Core 2.1 and later use the shared framework. -For .NET Core 2.0, the runtime package store feature is used implicitly by an ASP.NET Core app when the app is deployed as a [framework-dependent deployment](index.md#publish-framework-dependent) app. The targets in [`Microsoft.NET.Sdk.Web`](https://github.com/aspnet/websdk) include manifests referencing the implicit package store on the target system. Additionally, any framework-dependent app that depends on the `Microsoft.AspNetCore.All` package results in a published app that contains only the app and its assets and not the packages listed in the `Microsoft.AspNetCore.All` metapackage. It's assumed that those packages are present on the target system. +For .NET Core 2.0, the runtime package store feature is used implicitly by an ASP.NET Core app when the app is deployed as a [framework-dependent deployment](index.md#framework-dependent-deployment) app. The targets in [`Microsoft.NET.Sdk.Web`](https://github.com/aspnet/websdk) include manifests referencing the implicit package store on the target system. Additionally, any framework-dependent app that depends on the `Microsoft.AspNetCore.All` package results in a published app that contains only the app and its assets and not the packages listed in the `Microsoft.AspNetCore.All` metapackage. It's assumed that those packages are present on the target system. The runtime package store is installed on the host when the .NET SDK is installed. Other installers may provide the runtime package store, including Zip/tarball installations of the .NET SDK, `apt-get`, Red Hat Yum, the .NET Core Windows Server Hosting bundle, and manual runtime package store installations. -When deploying a [framework-dependent deployment](index.md#publish-framework-dependent) app, make sure that the target environment has the .NET SDK installed. If the app is deployed to an environment that doesn't include ASP.NET Core, you can opt out of the implicit store by specifying **\** set to `false` in the project file as in the following example: +When deploying a [framework-dependent deployment](index.md#framework-dependent-deployment) app, make sure that the target environment has the .NET SDK installed. If the app is deployed to an environment that doesn't include ASP.NET Core, you can opt out of the implicit store by specifying **\** set to `false` in the project file as in the following example: ```xml @@ -135,7 +135,7 @@ When deploying a [framework-dependent deployment](index.md#publish-framework-dep ``` > [!NOTE] -> For [self-contained deployment](index.md#publish-self-contained) apps, it's assumed that the target system doesn't necessarily contain the required manifest packages. Therefore, **\** cannot be set to `true` for an self-contained app. +> For [self-contained deployment](index.md#self-contained-deployment) apps, it's assumed that the target system doesn't necessarily contain the required manifest packages. Therefore, **\** cannot be set to `true` for an self-contained app. ## See also diff --git a/docs/core/deploying/single-file/overview.md b/docs/core/deploying/single-file/overview.md index 2034c312ad644..231548313ae64 100644 --- a/docs/core/deploying/single-file/overview.md +++ b/docs/core/deploying/single-file/overview.md @@ -8,7 +8,7 @@ ms.custom: kr2b-contr-experiment # Single-file deployment -Bundling all application-dependent files into a single binary provides an application developer with the attractive option to deploy and distribute the application as a single file. Single-file deployment is available for both the [framework-dependent deployment model](../index.md#publish-framework-dependent) and [self-contained applications](../index.md#publish-self-contained). +Bundling all application-dependent files into a single binary provides an application developer with the attractive option to deploy and distribute the application as a single file. Single-file deployment is available for both the [framework-dependent deployment model](../index.md#framework-dependent-deployment) and [self-contained applications](../index.md#self-contained-deployment). The size of the single file in a self-contained application is large since it includes the runtime and the framework libraries. In .NET 6, you can [publish trimmed](../trimming/trim-self-contained.md) to reduce the total size of trim-compatible applications. The single file deployment option can be combined with [ReadyToRun](../ready-to-run.md) and [Trim](../trimming/trim-self-contained.md) publish options. @@ -75,7 +75,7 @@ Publish a single file application using the [dotnet publish](../../tools/dotnet- dotnet publish -r linux-x64 -p:PublishSingleFile=true --self-contained false ``` -For more information, see [Publish .NET Core apps with .NET CLI](../deploy-with-cli.md). +For more information, see [.NET application publishing overview](../../deploying/index.md). # [Visual Studio](#tab/vs) @@ -105,7 +105,7 @@ Visual Studio creates reusable publishing profiles that control how your applica 1. Choose **Publish** to publish your app as a single file. -For more information, see [Publish .NET Core apps with Visual Studio](../deploy-with-vs.md). +For more information, see[.NET application publishing overview](../../deploying/index.md). --- @@ -235,7 +235,5 @@ Single file apps can be inspected using the [ILSpy tool](https://ilspy.net/). Th ## See also -- [.NET Core application deployment](../index.md) -- [Publish .NET apps with .NET CLI](../deploy-with-cli.md) -- [Publish .NET Core apps with Visual Studio](../deploy-with-vs.md) +- [.NET application publishing overview](../../deploying/index.md) - [`dotnet publish` command](../../tools/dotnet-publish.md) diff --git a/docs/core/deploying/snippets/deploy-with-vs/csharp/deploy.csproj b/docs/core/deploying/snippets/deploy-with-vs/csharp/deploy.csproj deleted file mode 100644 index af31fefa23aa5..0000000000000 --- a/docs/core/deploying/snippets/deploy-with-vs/csharp/deploy.csproj +++ /dev/null @@ -1,9 +0,0 @@ - - - - Exe - net8.0 - enable - - - diff --git a/docs/core/deploying/snippets/deploy-with-vs/csharp/deployment-example.cs b/docs/core/deploying/snippets/deploy-with-vs/csharp/deployment-example.cs deleted file mode 100644 index a5950f1af797e..0000000000000 --- a/docs/core/deploying/snippets/deploy-with-vs/csharp/deployment-example.cs +++ /dev/null @@ -1,35 +0,0 @@ -using System; -using System.Text.RegularExpressions; - -namespace Applications.ConsoleApps -{ - public class ConsoleParser - { - public static void Main() - { - Console.WriteLine("Enter any text, followed by :\n"); - String? s = Console.ReadLine(); - ShowWords(s ?? "You didn't enter anything."); - Console.Write("\nPress any key to continue... "); - Console.ReadKey(); - } - - private static void ShowWords(String s) - { - String pattern = @"\w+"; - var matches = Regex.Matches(s, pattern); - if (matches.Count == 0) - { - Console.WriteLine("\nNo words were identified in your input."); - } - else - { - Console.WriteLine($"\nThere are {matches.Count} words in your string:"); - for (int ctr = 0; ctr < matches.Count; ctr++) - { - Console.WriteLine($" #{ctr,2}: '{matches[ctr].Value}' at position {matches[ctr].Index}"); - } - } - } - } -} diff --git a/docs/core/deploying/snippets/deploy-with-vs/vb/deploy.vbproj b/docs/core/deploying/snippets/deploy-with-vs/vb/deploy.vbproj deleted file mode 100644 index 9dbe63c02ba99..0000000000000 --- a/docs/core/deploying/snippets/deploy-with-vs/vb/deploy.vbproj +++ /dev/null @@ -1,9 +0,0 @@ - - - - Exe - deploy - net8.0 - - - diff --git a/docs/core/deploying/snippets/deploy-with-vs/vb/deployment-example.vb b/docs/core/deploying/snippets/deploy-with-vs/vb/deployment-example.vb deleted file mode 100644 index a34a381e3ebba..0000000000000 --- a/docs/core/deploying/snippets/deploy-with-vs/vb/deployment-example.vb +++ /dev/null @@ -1,30 +0,0 @@ -Imports System.Text.RegularExpressions - -Namespace Applications.ConsoleApps - Public Module ConsoleParser - Public Sub Main() - Console.WriteLine("Enter any text, followed by :") - Console.WriteLine() - Dim s = Console.ReadLine() - ShowWords(s) - Console.Write($"{vbCrLf}Press any key to continue... ") - Console.ReadKey() - End Sub - - Private Sub ShowWords(s As String) - Dim pattern = "\w+" - Dim matches = Regex.Matches(s, pattern) - Console.WriteLine() - If matches.Count = 0 Then - Console.WriteLine("No words were identified in your input.") - Else - Console.WriteLine($"There are {matches.Count} words in your string:") - For ctr = 0 To matches.Count - 1 - Console.WriteLine($" #{ctr,2}: '{matches(ctr).Value}' at position {matches(ctr).Index}") - Next - End If - Console.WriteLine() - End Sub - End Module -End Namespace - diff --git a/docs/core/deploying/snippets/deploy-with-vs/xml/access-by-line.txt b/docs/core/deploying/snippets/deploy-with-vs/xml/access-by-line.txt deleted file mode 100644 index dacd1697af3fb..0000000000000 --- a/docs/core/deploying/snippets/deploy-with-vs/xml/access-by-line.txt +++ /dev/null @@ -1 +0,0 @@ -invariant.csproj: ~/docs/core/deploying/deploy-with-vs.md diff --git a/docs/core/deploying/snippets/deploy-with-vs/xml/invariant.csproj b/docs/core/deploying/snippets/deploy-with-vs/xml/invariant.csproj deleted file mode 100644 index 5032be67883f8..0000000000000 --- a/docs/core/deploying/snippets/deploy-with-vs/xml/invariant.csproj +++ /dev/null @@ -1,12 +0,0 @@ - - - - net8.0 - enable - - - - - - - diff --git a/docs/core/deploying/trimming/trim-self-contained.md b/docs/core/deploying/trimming/trim-self-contained.md index 2328573774638..d33ca4a1f80ad 100644 --- a/docs/core/deploying/trimming/trim-self-contained.md +++ b/docs/core/deploying/trimming/trim-self-contained.md @@ -7,7 +7,7 @@ ms.date: 04/03/2020 --- # Trim self-contained deployments and executables -The [framework-dependent deployment model](../index.md#publish-framework-dependent) has been the most successful deployment model since the inception of .NET. In this scenario, the application developer bundles only the application and third-party assemblies with the expectation that the .NET runtime and runtime libraries will be available in the client machine. This deployment model continues to be the dominant one in the latest .NET release, however, there are some scenarios where the framework-dependent model is not the best choice. The alternative is to publish a [self-contained application](../index.md#publish-self-contained), where the .NET runtime and runtime libraries are bundled together with the application and third-party assemblies. +The [framework-dependent deployment model](../index.md#framework-dependent-deployment) has been the most successful deployment model since the inception of .NET. In this scenario, the application developer bundles only the application and third-party assemblies with the expectation that the .NET runtime and runtime libraries will be available in the client machine. This deployment model continues to be the dominant one in the latest .NET release, however, there are some scenarios where the framework-dependent model is not the best choice. The alternative is to publish a [self-contained application](../index.md#self-contained-deployment), where the .NET runtime and runtime libraries are bundled together with the application and third-party assemblies. The trim-self-contained deployment model is a specialized version of the self-contained deployment model that is optimized to reduce deployment size. Minimizing deployment size is a critical requirement for some client-side scenarios like Blazor applications. Depending on the complexity of the application, only a subset of the framework assemblies are referenced, and a subset of the code within each assembly is required to run the application. The unused parts of the libraries are unnecessary and can be trimmed from the packaged application. @@ -51,7 +51,7 @@ Trimming is only supported for self-contained apps. `dotnet publish -r win-x64 -p:PublishTrimmed=true` -For more information, see [Publish .NET apps with .NET CLI](../deploy-with-cli.md). +For more information, see [.NET application publishing overview](../../deploying/index.md). ### Publish with Visual Studio @@ -67,11 +67,9 @@ For more information, see [Publish .NET apps with .NET CLI](../deploy-with-cli.m :::image type="content" source="../media/trim-self-contained/vs-publish-trimmed.png" alt-text="Visual studio publish page with Publish Trimmed selected."::: -For more information, see [Publish .NET Core apps with Visual Studio](../deploy-with-vs.md). +For more information, see [.NET application publishing overview](../../deploying/index.md). ## See also -- [.NET Core application deployment](../index.md). -- [Publish .NET apps with .NET CLI](../deploy-with-cli.md). -- [Publish .NET Core apps with Visual Studio](../deploy-with-vs.md). +- [.NET application publishing overview](../../deploying/index.md). - [dotnet publish command](../../tools/dotnet-publish.md). diff --git a/docs/core/docker/build-container.md b/docs/core/docker/build-container.md index 627cfeba46cff..0817b3adc1633 100644 --- a/docs/core/docker/build-container.md +++ b/docs/core/docker/build-container.md @@ -300,7 +300,7 @@ The `ENTRYPOINT` instruction sets `dotnet` as the host for the `DotNet.Docker.dl ENTRYPOINT ["./DotNet.Docker"] ``` -This causes the app to be executed directly, without `dotnet`, and instead relies on the app host and the underlying OS. For more information on deploying cross-platform binaries, see [Produce a cross-platform binary](../deploying/index.md#produce-an-executable). +This causes the app to be executed directly, without `dotnet`, and instead relies on the app host and the underlying OS. For more information on publishing cross-platform binaries, see [Cross-platform DLL deployment](../deploying/index.md#cross-platform-dll-deployment). To build the container, from your terminal, run the following command: diff --git a/docs/core/install/macos-notarization-issues.md b/docs/core/install/macos-notarization-issues.md index c5fece0a78580..0ab0881543138 100644 --- a/docs/core/install/macos-notarization-issues.md +++ b/docs/core/install/macos-notarization-issues.md @@ -36,7 +36,7 @@ You can also distribute your app without the apphost and rely on users to run yo dotnet run -p:UseAppHost=false ``` -An **appHost** is required when you publish your app [self-contained](../deploying/index.md#publish-self-contained) and you cannot disable it. +An **appHost** is required when you publish your app [self-contained](../deploying/index.md#self-contained-deployment) and you cannot disable it. For more information about the `UseAppHost` setting, see [MSBuild properties for Microsoft.NET.Sdk](../project-sdk/msbuild-props.md#useapphost). diff --git a/docs/core/native-interop/expose-components-to-com.md b/docs/core/native-interop/expose-components-to-com.md index f419bf1181d44..0d05727041dd9 100644 --- a/docs/core/native-interop/expose-components-to-com.md +++ b/docs/core/native-interop/expose-components-to-com.md @@ -123,7 +123,7 @@ There is a fully functional [COM server sample](https://github.com/dotnet/sample > [!IMPORTANT] > In .NET Framework, an "Any CPU" assembly can be consumed by both 32-bit and 64-bit clients. By default, in .NET Core, .NET 5, and later versions, "Any CPU" assemblies are accompanied by a 64-bit *\*.comhost.dll*. Because of this, they can only be consumed by 64-bit clients. That is the default because that is what the SDK represents. This behavior is identical to how the "self-contained" feature is published: by default it uses what the SDK provides. The `NETCoreSdkRuntimeIdentifier` MSBuild property determines the bitness of *\*.comhost.dll*. The managed part is actually bitness agnostic as expected, but the accompanying native asset defaults to the targeted SDK. -[Self-contained deployments](../deploying/index.md#publish-self-contained) of COM components are not supported. Only [framework-dependent deployments](../deploying/index.md#publish-framework-dependent) of COM components are supported. +[Self-contained deployments](../deploying/index.md#self-contained-deployment) of COM components are not supported. Only [framework-dependent deployments](../deploying/index.md#framework-dependent-deployment) of COM components are supported. Exposing COM components from [C++/CLI projects](/cpp/dotnet/dotnet-programming-with-cpp-cli-visual-cpp) via the [EnableComHosting property](../project-sdk/msbuild-props.md#enablecomhosting) is not supported. diff --git a/docs/core/project-sdk/msbuild-props.md b/docs/core/project-sdk/msbuild-props.md index 2f566e6c9ce97..f2923eeaca16d 100644 --- a/docs/core/project-sdk/msbuild-props.md +++ b/docs/core/project-sdk/msbuild-props.md @@ -546,7 +546,7 @@ The `PublishRelease` property informs `dotnet publish` to use the `Release` conf ### PublishSelfContained -The `PublishSelfContained` property informs `dotnet publish` to publish an app as a [self-contained app](../deploying/index.md#publish-self-contained). This property is useful when you can't use the `--self-contained` argument for the [dotnet publish](../tools/dotnet-publish.md) command—for example, when you're publishing at the solution level. In that case, you can add the `PublishSelfContained` MSBuild property to a project or *Directory.Build.Props* file. +The `PublishSelfContained` property informs `dotnet publish` to publish an app as a [self-contained app](../deploying/index.md#self-contained-deployment). This property is useful when you can't use the `--self-contained` argument for the [dotnet publish](../tools/dotnet-publish.md) command—for example, when you're publishing at the solution level. In that case, you can add the `PublishSelfContained` MSBuild property to a project or *Directory.Build.Props* file. This property was introduced in .NET 7. It's similar to the [SelfContained](#selfcontained) property, except that it's specific to the `publish` verb. It's recommended to use `PublishSelfContained` instead of `SelfContained`. @@ -626,7 +626,7 @@ The `SatelliteResourceLanguages` property lets you specify which languages you w ### SelfContained -The `SelfContained` property informs `dotnet build` and `dotnet publish` to build or publish an app as a [self-contained app](../deploying/index.md#publish-self-contained). This property is useful when you can't use the `--self-contained` argument with the [dotnet](../tools/dotnet.md) command—for example, when you're publishing at the solution level. In that case, you can add the `SelfContained` MSBuild property to a project or *Directory.Build.Props* file. +The `SelfContained` property informs `dotnet build` and `dotnet publish` to build or publish an app as a [self-contained app](../deploying/index.md#self-contained-deployment). This property is useful when you can't use the `--self-contained` argument with the [dotnet](../tools/dotnet.md) command—for example, when you're publishing at the solution level. In that case, you can add the `SelfContained` MSBuild property to a project or *Directory.Build.Props* file. This property is similar to the [PublishSelfContained](#publishselfcontained) property. It's recommended to use `PublishSelfContained` instead of `SelfContained` when possible. @@ -1623,7 +1623,7 @@ The following MSBuild properties are documented in this section: ### AppHostDotNetSearch -The `AppHostDotNetSearch` property configures how [the native executable](../deploying/index.md#produce-an-executable) produced for an application will search for a .NET installation. This property only impacts the executable produced on publish, not build. +The `AppHostDotNetSearch` property configures how [the native executable](../deploying/index.md#configure-net-install-search-behavior) produced for an application will search for a .NET installation. This property only impacts the executable produced on publish, not build. ```xml diff --git a/docs/core/rid-catalog.md b/docs/core/rid-catalog.md index d703e4e83d6c1..dcd84c686cf70 100644 --- a/docs/core/rid-catalog.md +++ b/docs/core/rid-catalog.md @@ -84,7 +84,7 @@ There are some considerations about RIDs that you have to keep in mind when work To be able to use RIDs, you have to know which RIDs exist. For the latest and complete version, see the [PortableRuntimeIdentifierGraph.json](https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.NETCore.Platforms/src/PortableRuntimeIdentifierGraph.json) in the [`dotnet/runtime`](https://github.com/dotnet/runtime) repository. -RIDs that are considered 'portable'—that is, aren't tied to a specific version or OS distribution—are the recommended choice. This means that portable RIDs should be used for both [building a platform-specific application](./deploying/index.md#platform-specific-and-framework-dependent) and [creating a NuGet package with RID-specific assets](/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders). +RIDs that are considered 'portable'—that is, aren't tied to a specific version or OS distribution—are the recommended choice. This means that portable RIDs should be used for both [building a platform-specific application](./deploying/index.md#native-dependencies) and [creating a NuGet package with RID-specific assets](/nuget/create-packages/supporting-multiple-target-frameworks#architecture-specific-folders). Starting with .NET 8, the default behavior of the .NET SDK and runtime is to only consider non-version-specific and non-distro-specific RIDs. When restoring and building, the SDK [uses a smaller portable RID graph](./compatibility/sdk/8.0/rid-graph.md). The [returns the platform for which the runtime was built](./compatibility/core-libraries/8.0/runtimeidentifier.md). At run time, .NET finds [RID-specific assets using a known set of portable RIDs](./compatibility/deployment/8.0/rid-asset-list.md). When building an application with RID-specific assets that may be ignored at runtime, the SDK will emit a warning: [NETSDK1206](./tools/sdk-errors/netsdk1206.md). diff --git a/docs/core/runtime-discovery/troubleshoot-app-launch.md b/docs/core/runtime-discovery/troubleshoot-app-launch.md index 548a4f17ed960..592eeeaacc143 100644 --- a/docs/core/runtime-discovery/troubleshoot-app-launch.md +++ b/docs/core/runtime-discovery/troubleshoot-app-launch.md @@ -9,7 +9,7 @@ zone_pivot_groups: operating-systems-set-one # Troubleshoot app launch failures -This article describes some common reasons and possible solutions for application launch failures. It relates to [framework-dependent applications](../deploying/index.md#publish-framework-dependent), which rely on a .NET installation on your machine. +This article describes some common reasons and possible solutions for application launch failures. It relates to [framework-dependent applications](../deploying/index.md#framework-dependent-deployment), which rely on a .NET installation on your machine. If you already know which .NET version you need, you can download it from [.NET downloads](https://dotnet.microsoft.com/download/dotnet). @@ -295,4 +295,4 @@ For more information, see [Multi-level lookup is disabled](../compatibility/depl - [Install .NET](../install/index.yml) - [.NET install locations](https://github.com/dotnet/designs/blob/main/accepted/2020/install-locations.md) - [Check installed .NET versions](../install/how-to-detect-installed-versions.md) -- [Framework-dependent applications](../deploying/index.md#publish-framework-dependent) +- [Framework-dependent applications](../deploying/index.md#framework-dependent-deployment) diff --git a/docs/core/tools/dotnet-clean.md b/docs/core/tools/dotnet-clean.md index aaf3f2b5a1534..912e73e70ab15 100644 --- a/docs/core/tools/dotnet-clean.md +++ b/docs/core/tools/dotnet-clean.md @@ -62,7 +62,7 @@ The MSBuild project or solution to clean. If a project or solution file is not s * **`-r|--runtime `** - Cleans the output folder of the specified runtime. This is used when a [self-contained deployment](../deploying/index.md#publish-self-contained) was created. + Cleans the output folder of the specified runtime. This is used when a [self-contained deployment](../deploying/index.md#self-contained-deployment) was created. [!INCLUDE [tl](../../../includes/cli-tl.md)] diff --git a/docs/core/tools/dotnet-publish.md b/docs/core/tools/dotnet-publish.md index ea8e7a14f3342..94ffde8e5747a 100644 --- a/docs/core/tools/dotnet-publish.md +++ b/docs/core/tools/dotnet-publish.md @@ -38,7 +38,7 @@ dotnet publish -h|--help - A *.runtimeconfig.json* file that specifies the shared runtime that the application expects, as well as other configuration options for the runtime (for example, garbage collection type). - The application's dependencies, which are copied from the NuGet cache into the output folder. -The `dotnet publish` command's output is ready for deployment to a hosting system (for example, a server, PC, Mac, laptop) for execution. It's the only officially supported way to prepare the application for deployment. Depending on the type of deployment that the project specifies, the hosting system may or may not have the .NET shared runtime installed on it. For more information, see [Publish .NET apps with the .NET CLI](../deploying/deploy-with-cli.md). +The `dotnet publish` command's output is ready for deployment to a hosting system (for example, a server, PC, Mac, laptop) for execution. It's the only officially supported way to prepare the application for deployment. Depending on the type of deployment that the project specifies, the hosting system may or may not have the .NET shared runtime installed on it. For more information, see [.NET application publishing overview](../deploying/index.md). ### Implicit restore @@ -196,7 +196,7 @@ For more information, see the following resources: - **`--sc|--self-contained [true|false]`** - Publishes the .NET runtime with your application so the runtime doesn't need to be installed on the target machine. Default is `true` if a runtime identifier is specified and the project is an executable project (not a library project). For more information, see [.NET application publishing](../deploying/index.md) and [Publish .NET apps with the .NET CLI](../deploying/deploy-with-cli.md). + Publishes the .NET runtime with your application so the runtime doesn't need to be installed on the target machine. Default is `true` if a runtime identifier is specified and the project is an executable project (not a library project). For more information, see [Self-contained deployment](../deploying/index.md#self-contained-deployment). If this option is used without specifying `true` or `false`, the default is `true`. In that case, don't put the solution or project argument immediately after `--self-contained`, because `true` or `false` is expected in that position. @@ -210,7 +210,7 @@ For more information, see the following resources: - **`-r|--runtime `** - Publishes the application for a given runtime. For a list of Runtime Identifiers (RIDs), see the [RID catalog](../rid-catalog.md). For more information, see [.NET application publishing](../deploying/index.md) and [Publish .NET apps with the .NET CLI](../deploying/deploy-with-cli.md). If you use this option, use `--self-contained` or `--no-self-contained` also. + Publishes the application for a given runtime. For a list of Runtime Identifiers (RIDs), see the [RID catalog](../rid-catalog.md). For more information, see [.NET application publishing overview](../deploying/index.md). If you use this option, use `--self-contained` or `--no-self-contained` also. [!INCLUDE [tl](../../../includes/cli-tl.md)] @@ -226,15 +226,15 @@ For more information, see the following resources: ## Examples -- Create a [framework-dependent cross-platform binary](../deploying/index.md#produce-a-cross-platform-binary) for the project in the current directory: +- Create a [framework-dependent cross-platform binary](../deploying/index.md#cross-platform-dll-deployment) for the project in the current directory: ```dotnetcli dotnet publish ``` - Starting with .NET Core 3.0 SDK, this example also creates a [framework-dependent executable](../deploying/index.md#publish-framework-dependent) for the current platform. + Starting with .NET Core 3.0 SDK, this example also creates a [framework-dependent executable](../deploying/index.md#framework-dependent-deployment) for the current platform. -- Create a [self-contained executable](../deploying/index.md#publish-self-contained) for the project in the current directory, for a specific runtime: +- Create a [self-contained executable](../deploying/index.md#self-contained-deployment) for the project in the current directory, for a specific runtime: ```dotnetcli dotnet publish --runtime osx-x64 @@ -242,7 +242,7 @@ For more information, see the following resources: The RID must be in the project file. -- Create a [framework-dependent executable](../deploying/index.md#publish-framework-dependent) for the project in the current directory, for a specific platform: +- Create a [framework-dependent executable](../deploying/index.md#framework-dependent-deployment) for the project in the current directory, for a specific platform: ```dotnetcli dotnet publish --runtime osx-x64 --self-contained false @@ -271,7 +271,6 @@ For more information, see the following resources: ## See also - [.NET application publishing overview](../deploying/index.md) -- [Publish .NET apps with the .NET CLI](../deploying/deploy-with-cli.md) - [Target frameworks](../../standard/frameworks.md) - [Runtime Identifier (RID) catalog](../rid-catalog.md) - [Containerize a .NET app with dotnet publish](../containers/sdk-publish.md) diff --git a/docs/core/tools/sdk-errors/netsdk1071.md b/docs/core/tools/sdk-errors/netsdk1071.md index e01bed73f07a3..2b85dbed857e6 100644 --- a/docs/core/tools/sdk-errors/netsdk1071.md +++ b/docs/core/tools/sdk-errors/netsdk1071.md @@ -24,7 +24,7 @@ Since the `TargetFramework` automatically brings in a version of the metapackage To resolve this: 1. When you target .NET Core or .NET Standard, consider avoiding explicit references to `Microsoft.NETCore.App` or `NETStandard.Library` in your project file. -2. If you need a specific version of the runtime when targeting .NET Core, use the ``property instead of referencing the metapackage directly. As an example, this could happen if you're using [self-contained deployments](../../deploying/index.md#publish-self-contained) and need a specific patch of the 1.0.0 LTS runtime. +2. If you need a specific version of the runtime when targeting .NET Core, use the ``property instead of referencing the metapackage directly. As an example, this could happen if you're using [self-contained deployments](../../deploying/index.md#self-contained-deployment) and need a specific patch of the 1.0.0 LTS runtime. 3. If you need a specific version of `NetStandard.Library` when targeting .NET Standard, you can use the `` property and set it to the version you need. 4. Don't explicitly add or update references to either `Microsoft.NETCore.App` or `NETSTandard.Library` in .NET Framework projects. NuGet automatically installs any version of `NETStandard.Library` you need when using a .NET Standard-based NuGet package. 5. Do not specify a version for `Microsoft.AspNetCore.App` or `Microsoft.AspNetCore.All` when using .NET Core 2.1+, as the .NET SDK automatically selects the appropriate version. (Note: This only works when targeting .NET Core 2.1 if the project also uses `Microsoft.NET.Sdk.Web`. This problem was resolved in the .NET Core 2.2 SDK.) diff --git a/docs/core/tools/troubleshoot-usage-issues.md b/docs/core/tools/troubleshoot-usage-issues.md index 809852ddf71f4..ba7fcd5fc23bb 100644 --- a/docs/core/tools/troubleshoot-usage-issues.md +++ b/docs/core/tools/troubleshoot-usage-issues.md @@ -69,7 +69,7 @@ If you're trying to run a .NET tool that was installed with a specified path, yo ### Runtime not found -.NET tools are [framework-dependent applications](../deploying/index.md#publish-framework-dependent), which means they rely on a .NET runtime installed on your machine. If the expected runtime isn't found, they follow normal .NET runtime roll-forward rules such as: +.NET tools are [framework-dependent applications](../deploying/index.md#framework-dependent-deployment), which means they rely on a .NET runtime installed on your machine. If the expected runtime isn't found, they follow normal .NET runtime roll-forward rules such as: - An application rolls forward to the highest patch release of the specified major and minor version. - If there's no matching runtime with a matching major and minor version number, the next higher minor version is used. diff --git a/docs/core/tutorials/publishing-with-visual-studio-code.md b/docs/core/tutorials/publishing-with-visual-studio-code.md index e724d0e997a16..1763c8e82c5a6 100644 --- a/docs/core/tutorials/publishing-with-visual-studio-code.md +++ b/docs/core/tutorials/publishing-with-visual-studio-code.md @@ -62,11 +62,11 @@ In the following steps, you'll look at the files created by the publish process. - *HelloWorld.dll* - This is the [framework-dependent deployment](../deploying/deploy-with-cli.md#framework-dependent-deployment) version of the application. To run this dynamic link library, enter `dotnet HelloWorld.dll` at a command prompt. This method of running the app works on any platform that has the .NET runtime installed. + This is the [framework-dependent deployment](../deploying/index.md#cross-platform-dll-deployment) version of the application. To run this dynamic link library, enter `dotnet HelloWorld.dll` at a command prompt. This method of running the app works on any platform that has the .NET runtime installed. - *HelloWorld.exe* (*HelloWorld* on Linux or macOS.) - This is the [framework-dependent executable](../deploying/deploy-with-cli.md#framework-dependent-executable) version of the application. The file is operating-system-specific. + This is the [framework-dependent executable](../deploying/index.md#framework-dependent-deployment) version of the application. The file is operating-system-specific. - *HelloWorld.pdb* (optional for deployment) @@ -98,8 +98,7 @@ In the following steps, you'll look at the files created by the publish process. ## Additional resources -- [.NET application deployment](../deploying/index.md) -- [Publish .NET apps with the .NET CLI](../deploying/deploy-with-cli.md) +- [.NET application publishing overview](../deploying/index.md) - [`dotnet publish`](../tools/dotnet-publish.md) - [Use the .NET SDK in continuous integration (CI) environments](../../devops/dotnet-cli-and-continuous-integration.md) diff --git a/docs/core/tutorials/publishing-with-visual-studio.md b/docs/core/tutorials/publishing-with-visual-studio.md index ee2d29563d5dc..6f23304a0571d 100644 --- a/docs/core/tutorials/publishing-with-visual-studio.md +++ b/docs/core/tutorials/publishing-with-visual-studio.md @@ -54,7 +54,7 @@ In the following steps, you'll look at the files created by the publish process. 1. In **Solution Explorer**, select **Show all files**. -1. In the project folder, expand *bin/Release/net7.0/publish*. +1. In the project folder, expand *bin/Release/{net}/publish*. (Where {net} is the target framework folder, such as _net8.0_.) :::image type="content" source="media/publishing-with-visual-studio/published-files-output-net8.png" alt-text="Solution Explorer showing published files"::: @@ -66,11 +66,11 @@ In the following steps, you'll look at the files created by the publish process. - *HelloWorld.dll* - This is the [framework-dependent deployment](../deploying/deploy-with-cli.md#framework-dependent-deployment) version of the application. To execute this dynamic link library, enter `dotnet HelloWorld.dll` at a command prompt. This method of running the app works on any platform that has the .NET runtime installed. + This is the [framework-dependent deployment](../deploying/index.md#cross-platform-dll-deployment) version of the application. To execute this dynamic link library, enter `dotnet HelloWorld.dll` at a command prompt. This method of running the app works on any platform that has the .NET runtime installed. - *HelloWorld.exe* - This is the [framework-dependent executable](../deploying/deploy-with-cli.md#framework-dependent-executable) version of the application. To run it, enter `HelloWorld.exe` at a command prompt. The file is operating-system-specific. + This is the [framework-dependent executable](../deploying/index.md#framework-dependent-deployment) version of the application. To run it, enter `HelloWorld.exe` at a command prompt. The file is operating-system-specific. - *HelloWorld.pdb* (optional for deployment) @@ -104,8 +104,7 @@ In the following steps, you'll look at the files created by the publish process. ## Additional resources -- [.NET application deployment](../deploying/index.md) -- [Publish .NET apps with the .NET CLI](../deploying/deploy-with-cli.md) +- [.NET application publishing overview](../deploying/index.md) - [`dotnet publish`](../tools/dotnet-publish.md) - [Tutorial: Publish a .NET console application using Visual Studio Code](publishing-with-visual-studio-code.md) - [Use the .NET SDK in continuous integration (CI) environments](../../devops/dotnet-cli-and-continuous-integration.md) diff --git a/docs/core/versions/selection.md b/docs/core/versions/selection.md index 083e7a04f2a76..245c105ccf13b 100644 --- a/docs/core/versions/selection.md +++ b/docs/core/versions/selection.md @@ -81,7 +81,7 @@ For more information, see [.NET 5 and .NET Standard](../../standard/net-standard ## Framework-dependent apps roll-forward -When you run an application from source with [`dotnet run`](../tools/dotnet-run.md), from a [**framework-dependent deployment**](../deploying/index.md#publish-framework-dependent) with [`dotnet myapp.dll`](../tools/dotnet.md#description), or from a [**framework-dependent executable**](../deploying/index.md#publish-framework-dependent) with `myapp.exe`, the `dotnet` executable is the **host** for the application. +When you run an application from source with [`dotnet run`](../tools/dotnet-run.md), from a [**framework-dependent deployment**](../deploying/index.md#framework-dependent-deployment) with [`dotnet myapp.dll`](../tools/dotnet.md#description), or from a [**framework-dependent executable**](../deploying/index.md#framework-dependent-deployment) with `myapp.exe`, the `dotnet` executable is the **host** for the application. The host chooses the latest patch version installed on the machine. For example, if you specified `net5.0` in your project file, and `5.0.2` is the latest .NET runtime installed, the `5.0.2` runtime is used. @@ -173,7 +173,7 @@ Then the resolved version is as follows in each case: ## Self-contained deployments include the selected runtime -You can publish an application as a [**self-contained distribution**](../deploying/index.md#publish-self-contained). This approach bundles the .NET runtime and libraries with your application. Self-contained deployments don't have a dependency on runtime environments. Runtime version selection occurs at publishing time, not run time. +You can publish an application as a [**self-contained distribution**](../deploying/index.md#self-contained-deployment). This approach bundles the .NET runtime and libraries with your application. Self-contained deployments don't have a dependency on runtime environments. Runtime version selection occurs at publishing time, not run time. The *restore* event that occurs when publishing selects the latest patch version of the given runtime family. For example, `dotnet publish` will select .NET 5.0.3 if it's the latest patch version in the .NET 5 runtime family. The target framework (including the latest installed security patches) is packaged with the application. diff --git a/docs/core/whats-new/dotnet-9/runtime.md b/docs/core/whats-new/dotnet-9/runtime.md index c23d90899ee93..0f3013839c87b 100644 --- a/docs/core/whats-new/dotnet-9/runtime.md +++ b/docs/core/whats-new/dotnet-9/runtime.md @@ -74,7 +74,7 @@ CET imposes some limitations on CET-enabled processes and can result in a small ## .NET install search behavior -.NET apps can now be configured for how they should [search for the .NET runtime](../../deploying/deploy-with-cli.md#configure-net-install-search-behavior). This capability can be used with private runtime installations or to more strongly control the execution environment. +.NET apps can now be configured for how they should [search for the .NET runtime](../../deploying/index.md#configure-net-install-search-behavior). This capability can be used with private runtime installations or to more strongly control the execution environment. ## Performance improvements diff --git a/docs/core/whats-new/dotnet-core-2-2.md b/docs/core/whats-new/dotnet-core-2-2.md index 0d9c49d531114..e34f5eeee6018 100644 --- a/docs/core/whats-new/dotnet-core-2-2.md +++ b/docs/core/whats-new/dotnet-core-2-2.md @@ -12,7 +12,7 @@ ms.date: 12/04/2018 ## New deployment mode -Starting with .NET Core 2.2, you can deploy [framework-dependent executables](../deploying/index.md#publish-framework-dependent), which are **.exe** files instead of **.dll** files. Functionally similar to framework-dependent deployments, framework-dependent executables (FDE) still rely on the presence of a shared system-wide version of .NET Core to run. Your app contains only your code and any third-party dependencies. Unlike framework-dependent deployments, FDEs are platform-specific. +Starting with .NET Core 2.2, you can deploy [framework-dependent executables](../deploying/index.md#framework-dependent-deployment), which are **.exe** files instead of **.dll** files. Functionally similar to framework-dependent deployments, framework-dependent executables (FDE) still rely on the presence of a shared system-wide version of .NET Core to run. Your app contains only your code and any third-party dependencies. Unlike framework-dependent deployments, FDEs are platform-specific. This new deployment mode has the distinct advantage of building an executable instead of a library, which means you can run your app directly without invoking `dotnet` first. diff --git a/docs/core/whats-new/dotnet-core-3-0.md b/docs/core/whats-new/dotnet-core-3-0.md index 88a14598d26de..1282026525dd8 100644 --- a/docs/core/whats-new/dotnet-core-3-0.md +++ b/docs/core/whats-new/dotnet-core-3-0.md @@ -56,7 +56,7 @@ If you're using Visual Studio, you need [Visual Studio 2019](https://visualstudi ### Default executables -.NET Core now builds [framework-dependent executables](../deploying/index.md#publish-framework-dependent) by default. This behavior is new for applications that use a globally installed version of .NET Core. Previously, only [self-contained deployments](../deploying/index.md#publish-self-contained) would produce an executable. +.NET Core now builds [framework-dependent executables](../deploying/index.md#framework-dependent-deployment) by default. This behavior is new for applications that use a globally installed version of .NET Core. Previously, only [self-contained deployments](../deploying/index.md#self-contained-deployment) would produce an executable. During `dotnet build` or `dotnet publish`, an executable (known as the **appHost**) is created that matches the environment and platform of the SDK you're using. You can expect the same things with these executables as you would other native executables, such as: @@ -71,7 +71,7 @@ Starting with the notarized .NET Core SDK 3.0 for macOS, the setting to produce When the appHost setting is enabled, .NET Core generates a native Mach-O executable when you build or publish. Your app runs in the context of the appHost when it is run from source code with the `dotnet run` command, or by starting the Mach-O executable directly. -Without the appHost, the only way a user can start a [framework-dependent](../deploying/index.md#publish-framework-dependent) app is with the `dotnet ` command. An appHost is always created when you publish your app [self-contained](../deploying/index.md#publish-self-contained). +Without the appHost, the only way a user can start a [framework-dependent](../deploying/index.md#framework-dependent-deployment) app is with the `dotnet ` command. An appHost is always created when you publish your app [self-contained](../deploying/index.md#self-contained-deployment). You can either configure the appHost at the project level, or toggle the appHost for a specific `dotnet` command with the `-p:UseAppHost` parameter: @@ -328,7 +328,7 @@ Windows offers a rich native API in the form of flat C APIs, COM, and WinRT. Whi [MSIX](/windows/msix/) is a new Windows application package format. It can be used to deploy .NET Core 3.0 desktop applications to Windows 10. -The [Windows Application Packaging Project](/windows/uwp/porting/desktop-to-uwp-packaging-dot-net), available in Visual Studio 2019, allows you to create MSIX packages with [self-contained](../deploying/index.md#publish-self-contained) .NET Core applications. +The [Windows Application Packaging Project](/windows/uwp/porting/desktop-to-uwp-packaging-dot-net), available in Visual Studio 2019, allows you to create MSIX packages with [self-contained](../deploying/index.md#self-contained-deployment) .NET Core applications. The .NET Core project file must specify the supported runtimes in the `` property: diff --git a/docs/core/whats-new/dotnet-core-3-1.md b/docs/core/whats-new/dotnet-core-3-1.md index cffe958ce594f..b521930017199 100644 --- a/docs/core/whats-new/dotnet-core-3-1.md +++ b/docs/core/whats-new/dotnet-core-3-1.md @@ -39,7 +39,7 @@ Starting with the notarized .NET Core SDK 3.1 for macOS, the appHost setting is When the appHost setting is enabled, .NET Core generates a native Mach-O executable when you build or publish. Your app runs in the context of the appHost when it is run from source code with the `dotnet run` command, or by starting the Mach-O executable directly. -Without the appHost, the only way a user can start a [framework-dependent](../deploying/index.md#publish-framework-dependent) app is with the `dotnet ` command. An appHost is always created when you publish your app [self-contained](../deploying/index.md#publish-self-contained). +Without the appHost, the only way a user can start a [framework-dependent](../deploying/index.md#framework-dependent-deployment) app is with the `dotnet ` command. An appHost is always created when you publish your app [self-contained](../deploying/index.md#self-contained-deployment). You can either configure the appHost at the project level, or toggle the appHost for a specific `dotnet` command with the `-p:UseAppHost` parameter: diff --git a/docs/navigate/devops-testing/toc.yml b/docs/navigate/devops-testing/toc.yml index 0221c6819b87b..57a6ce1b45d6c 100644 --- a/docs/navigate/devops-testing/toc.yml +++ b/docs/navigate/devops-testing/toc.yml @@ -289,14 +289,10 @@ items: href: ../../core/testing/unit-testing-code-coverage.md - name: Live unit test with Visual Studio href: /visualstudio/test/live-unit-testing-start?toc=/dotnet/navigate/devops-testing/toc.json&bc=/dotnet/breadcrumb/toc.json - - name: Deployment models + - name: Publishing items: - name: Overview href: ../../core/deploying/index.md - - name: Deploy apps with Visual Studio - href: ../../core/deploying/deploy-with-vs.md - - name: Publish apps with the CLI - href: ../../core/deploying/deploy-with-cli.md - name: Create a NuGet package with the CLI href: ../../core/deploying/creating-nuget-packages.md - name: Self-contained deployment runtime roll forward diff --git a/docs/navigate/tools-diagnostics/index.yml b/docs/navigate/tools-diagnostics/index.yml index 7baf8b595fe8e..521fd61399d04 100644 --- a/docs/navigate/tools-diagnostics/index.yml +++ b/docs/navigate/tools-diagnostics/index.yml @@ -67,7 +67,7 @@ landingContent: - linkListType: deploy links: - text: Publish apps - url: ../../core/deploying/deploy-with-cli.md + url: ../../core/deploying/index.md # Card - title: Global and local tools diff --git a/docs/standard/glossary.md b/docs/standard/glossary.md index f4f9b6add966a..52400145ca418 100644 --- a/docs/standard/glossary.md +++ b/docs/standard/glossary.md @@ -115,7 +115,7 @@ The word "framework" has a different meaning in the following terms: - [shared framework](#shared-framework) - [target framework](#target-framework) - [TFM (target framework moniker)](#tfm) -- [framework-dependent app](../core/deploying/index.md#publish-framework-dependent) +- [framework-dependent app](../core/deploying/index.md#framework-dependent-deployment) Sometimes "framework" refers to an [implementation of .NET](#implementation-of-net). @@ -289,7 +289,7 @@ The word "runtime" has a different meaning in some contexts: - *.NET runtime* on the [.NET 5 download page](https://dotnet.microsoft.com/download/dotnet/5.0). - You can download the *.NET runtime* or other runtimes, such as the *ASP.NET Core runtime*. A *runtime* in this usage is the set of components that must be installed on a machine to run a [framework-dependent](../core/deploying/index.md#publish-framework-dependent) app on the machine. The .NET runtime includes the [CLR](#clr) and the .NET [shared framework](#shared-framework), which provides the [BCL](#bcl). + You can download the *.NET runtime* or other runtimes, such as the *ASP.NET Core runtime*. A *runtime* in this usage is the set of components that must be installed on a machine to run a [framework-dependent](../core/deploying/index.md#framework-dependent-deployment) app on the machine. The .NET runtime includes the [CLR](#clr) and the .NET [shared framework](#shared-framework), which provides the [BCL](#bcl). - *.NET runtime libraries* @@ -310,7 +310,7 @@ Meaning depends on context. The *.NET shared framework* refers to the libraries There are other shared frameworks. The *ASP.NET Core shared framework* refers to the libraries included in the [ASP.NET Core runtime](#runtime), which includes the BCL plus additional APIs for use by web apps. -For [framework-dependent apps](../core/deploying/index.md#publish-framework-dependent), the shared framework consists of libraries that are contained in assemblies installed in a folder on the machine that runs the app. For [self-contained apps](../core/deploying/index.md#publish-self-contained), the shared framework assemblies are included with the app. +For [framework-dependent apps](../core/deploying/index.md#framework-dependent-deployment), the shared framework consists of libraries that are contained in assemblies installed in a folder on the machine that runs the app. For [self-contained apps](../core/deploying/index.md#self-contained-deployment), the shared framework assemblies are included with the app. For more information, see [Deep-dive into .NET Core primitives, part 2: the shared framework](https://natemcmaster.com/blog/2018/08/29/netcore-primitives-2/). diff --git a/docs/standard/runtime-libraries-overview.md b/docs/standard/runtime-libraries-overview.md index 05023f12d0bd0..1230de6cbc559 100644 --- a/docs/standard/runtime-libraries-overview.md +++ b/docs/standard/runtime-libraries-overview.md @@ -42,4 +42,4 @@ The following table shows some examples of package-provided libraries. * [Introduction to .NET](../core/introduction.md) * [Install .NET SDK or runtime](../core/install/index.yml) * [Select the installed .NET SDK or runtime version to use](../core/versions/selection.md) -* [Publish framework-dependent apps](../core/deploying/index.md#publish-framework-dependent) +* [Publish framework-dependent apps](../core/deploying/index.md#framework-dependent-deployment) From 515ad2288e8386930a8c99cfe913116e2d99187d Mon Sep 17 00:00:00 2001 From: Azure SDK Bot <53356347+azure-sdk@users.noreply.github.com> Date: Thu, 21 Aug 2025 20:44:03 -0700 Subject: [PATCH 6/7] Update package index with latest published versions (#48059) --- docs/azure/includes/dotnet-all.md | 2 +- docs/azure/includes/dotnet-new.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/azure/includes/dotnet-all.md b/docs/azure/includes/dotnet-all.md index 88b42db2a0eca..c283779890a30 100644 --- a/docs/azure/includes/dotnet-all.md +++ b/docs/azure/includes/dotnet-all.md @@ -345,7 +345,7 @@ | Resource Management - Reservations | NuGet [1.4.1](https://www.nuget.org/packages/Azure.ResourceManager.Reservations/1.4.1) | [docs](/dotnet/api/overview/azure/ResourceManager.Reservations-readme) | GitHub [1.4.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.Reservations_1.4.1/sdk/reservations/Azure.ResourceManager.Reservations/) | | Resource Management - Resource Connector | NuGet [1.0.0-beta.3](https://www.nuget.org/packages/Azure.ResourceManager.ResourceConnector/1.0.0-beta.3) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceConnector-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.3](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceConnector_1.0.0-beta.3/sdk/resourceconnector/Azure.ResourceManager.ResourceConnector/) | | Resource Management - Resource Graph | NuGet [1.0.1](https://www.nuget.org/packages/Azure.ResourceManager.ResourceGraph/1.0.1)
NuGet [1.1.0-beta.4](https://www.nuget.org/packages/Azure.ResourceManager.ResourceGraph/1.1.0-beta.4) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceGraph-readme) | GitHub [1.0.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceGraph_1.0.1/sdk/resourcegraph/Azure.ResourceManager.ResourceGraph/)
GitHub [1.1.0-beta.4](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceGraph_1.1.0-beta.4/sdk/resourcegraph/Azure.ResourceManager.ResourceGraph/) | -| Resource Management - Resource Health | NuGet [1.0.0](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.0.0)
NuGet [1.1.0-beta.4](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.1.0-beta.4) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceHealth-readme) | GitHub [1.0.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.0.0/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/)
GitHub [1.1.0-beta.4](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.1.0-beta.4/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/) | +| Resource Management - Resource Health | NuGet [1.0.0](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.0.0)
NuGet [1.1.0-beta.5](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.1.0-beta.5) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceHealth-readme) | GitHub [1.0.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.0.0/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/)
GitHub [1.1.0-beta.5](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.1.0-beta.5/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/) | | Resource Management - Resource Manager | NuGet [1.13.2](https://www.nuget.org/packages/Azure.ResourceManager/1.13.2)
NuGet [1.14.0-beta.1](https://www.nuget.org/packages/Azure.ResourceManager/1.14.0-beta.1) | [docs](/dotnet/api/overview/azure/ResourceManager-readme) | GitHub [1.13.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager_1.13.2/sdk/resourcemanager/Azure.ResourceManager/)
GitHub [1.14.0-beta.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager_1.14.0-beta.1/sdk/resourcemanager/Azure.ResourceManager/) | | Resource Management - Resource Mover | NuGet [1.1.1](https://www.nuget.org/packages/Azure.ResourceManager.ResourceMover/1.1.1)
NuGet [1.1.2-beta.2](https://www.nuget.org/packages/Azure.ResourceManager.ResourceMover/1.1.2-beta.2) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceMover-readme) | GitHub [1.1.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceMover_1.1.1/sdk/resourcemover/Azure.ResourceManager.ResourceMover/)
GitHub [1.1.2-beta.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceMover_1.1.2-beta.2/sdk/resourcemover/Azure.ResourceManager.ResourceMover/) | | Resource Management - Resources | NuGet [1.11.1](https://www.nuget.org/packages/Azure.ResourceManager.Resources/1.11.1) | [docs](/dotnet/api/overview/azure/ResourceManager.Resources-readme) | GitHub [1.11.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.Resources_1.11.1/sdk/resources/Azure.ResourceManager.Resources/) | diff --git a/docs/azure/includes/dotnet-new.md b/docs/azure/includes/dotnet-new.md index f77f23e176816..bd4bd505eba8f 100644 --- a/docs/azure/includes/dotnet-new.md +++ b/docs/azure/includes/dotnet-new.md @@ -356,7 +356,7 @@ | Resource Management - Reservations | NuGet [1.4.1](https://www.nuget.org/packages/Azure.ResourceManager.Reservations/1.4.1) | [docs](/dotnet/api/overview/azure/ResourceManager.Reservations-readme) | GitHub [1.4.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.Reservations_1.4.1/sdk/reservations/Azure.ResourceManager.Reservations/) | | Resource Management - Resource Connector | NuGet [1.0.0-beta.3](https://www.nuget.org/packages/Azure.ResourceManager.ResourceConnector/1.0.0-beta.3) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceConnector-readme?view=azure-dotnet-preview&preserve-view=true) | GitHub [1.0.0-beta.3](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceConnector_1.0.0-beta.3/sdk/resourceconnector/Azure.ResourceManager.ResourceConnector/) | | Resource Management - Resource Graph | NuGet [1.0.1](https://www.nuget.org/packages/Azure.ResourceManager.ResourceGraph/1.0.1)
NuGet [1.1.0-beta.4](https://www.nuget.org/packages/Azure.ResourceManager.ResourceGraph/1.1.0-beta.4) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceGraph-readme) | GitHub [1.0.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceGraph_1.0.1/sdk/resourcegraph/Azure.ResourceManager.ResourceGraph/)
GitHub [1.1.0-beta.4](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceGraph_1.1.0-beta.4/sdk/resourcegraph/Azure.ResourceManager.ResourceGraph/) | -| Resource Management - Resource Health | NuGet [1.0.0](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.0.0)
NuGet [1.1.0-beta.4](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.1.0-beta.4) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceHealth-readme) | GitHub [1.0.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.0.0/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/)
GitHub [1.1.0-beta.4](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.1.0-beta.4/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/) | +| Resource Management - Resource Health | NuGet [1.0.0](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.0.0)
NuGet [1.1.0-beta.5](https://www.nuget.org/packages/Azure.ResourceManager.ResourceHealth/1.1.0-beta.5) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceHealth-readme) | GitHub [1.0.0](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.0.0/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/)
GitHub [1.1.0-beta.5](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceHealth_1.1.0-beta.5/sdk/resourcehealth/Azure.ResourceManager.ResourceHealth/) | | Resource Management - Resource Manager | NuGet [1.13.2](https://www.nuget.org/packages/Azure.ResourceManager/1.13.2)
NuGet [1.14.0-beta.1](https://www.nuget.org/packages/Azure.ResourceManager/1.14.0-beta.1) | [docs](/dotnet/api/overview/azure/ResourceManager-readme) | GitHub [1.13.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager_1.13.2/sdk/resourcemanager/Azure.ResourceManager/)
GitHub [1.14.0-beta.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager_1.14.0-beta.1/sdk/resourcemanager/Azure.ResourceManager/) | | Resource Management - Resource Mover | NuGet [1.1.1](https://www.nuget.org/packages/Azure.ResourceManager.ResourceMover/1.1.1)
NuGet [1.1.2-beta.2](https://www.nuget.org/packages/Azure.ResourceManager.ResourceMover/1.1.2-beta.2) | [docs](/dotnet/api/overview/azure/ResourceManager.ResourceMover-readme) | GitHub [1.1.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceMover_1.1.1/sdk/resourcemover/Azure.ResourceManager.ResourceMover/)
GitHub [1.1.2-beta.2](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.ResourceMover_1.1.2-beta.2/sdk/resourcemover/Azure.ResourceManager.ResourceMover/) | | Resource Management - Resources | NuGet [1.11.1](https://www.nuget.org/packages/Azure.ResourceManager.Resources/1.11.1) | [docs](/dotnet/api/overview/azure/ResourceManager.Resources-readme) | GitHub [1.11.1](https://github.com/Azure/azure-sdk-for-net/tree/Azure.ResourceManager.Resources_1.11.1/sdk/resources/Azure.ResourceManager.Resources/) | From 4c79c28ba318889f747fcf30f919aac1cda84ce7 Mon Sep 17 00:00:00 2001 From: fcdeveloper00 Date: Thu, 21 Aug 2025 20:45:45 -0700 Subject: [PATCH 7/7] Update configuration-providers.md (#48055) --- docs/core/extensions/configuration-providers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/core/extensions/configuration-providers.md b/docs/core/extensions/configuration-providers.md index 6476fda3b89af..f6f31d284a5b2 100644 --- a/docs/core/extensions/configuration-providers.md +++ b/docs/core/extensions/configuration-providers.md @@ -47,7 +47,7 @@ The preceding code: - `reloadOnChange: true`: The file is reloaded when changes are saved. > [!IMPORTANT] -> When [adding configuration providers](https://github.com/dotnet/runtime/blob/main/src%2Flibraries%2FMicrosoft.Extensions.Configuration%2Fsrc%2FConfigurationBuilder.cs#L30-L34) with , the added configuration provider is added to the end of the end of the `IConfigurationSource` list. When keys are found by multiple providers, the last provider to read the key overrides previous providers. +> When [adding configuration providers](https://github.com/dotnet/runtime/blob/main/src%2Flibraries%2FMicrosoft.Extensions.Configuration%2Fsrc%2FConfigurationBuilder.cs#L30-L34) with , the added configuration provider is added to the end of the `IConfigurationSource` list. When keys are found by multiple providers, the last provider to read the key overrides previous providers. An example *appsettings.json* file with various configuration settings follows: