diff --git a/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md b/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md
index ba22eaefbd1d8..e71379391f518 100644
--- a/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md
+++ b/docs/architecture/microservices/architect-microservice-container-applications/containerize-monolithic-applications.md
@@ -1,7 +1,7 @@
---
title: Containerizing monolithic applications
description: Containerizing monolithic applications, although doesn't get all the benefits from the microservices architecture, has important deployment benefits that can be delivered right away.
-ms.date: 01/30/2020
+ms.date: 11/19/2021
---
# Containerizing monolithic applications
@@ -55,7 +55,7 @@ Whether you want to get validation of a container deployed to Azure or when an a
-**Figure 4-4**. Publishing a single-container application to Azure App Service from Visual Studio 2019
+**Figure 4-4**. Publishing a single-container application to Azure App Service from Visual Studio 2022
Without Docker, if you needed other capabilities, frameworks, or dependencies that aren't supported in Azure App Service, you had to wait until the Azure team updated those dependencies in App Service. Or you had to switch to other services like Azure Cloud Services or VMs, where you had further control and you could install a required component or framework for your application.
diff --git a/docs/architecture/microservices/architect-microservice-container-applications/media/containerize-monolithic-applications/publish-azure-app-service-container.png b/docs/architecture/microservices/architect-microservice-container-applications/media/containerize-monolithic-applications/publish-azure-app-service-container.png
index 23b378702604c..cefbb64f086da 100644
Binary files a/docs/architecture/microservices/architect-microservice-container-applications/media/containerize-monolithic-applications/publish-azure-app-service-container.png and b/docs/architecture/microservices/architect-microservice-container-applications/media/containerize-monolithic-applications/publish-azure-app-service-container.png differ
diff --git a/docs/architecture/microservices/architect-microservice-container-applications/media/scalable-available-multi-container-microservice-applications/azure-container-apps-logo.png b/docs/architecture/microservices/architect-microservice-container-applications/media/scalable-available-multi-container-microservice-applications/azure-container-apps-logo.png
new file mode 100644
index 0000000000000..8f41e7cf9892d
Binary files /dev/null and b/docs/architecture/microservices/architect-microservice-container-applications/media/scalable-available-multi-container-microservice-applications/azure-container-apps-logo.png differ
diff --git a/docs/architecture/microservices/architect-microservice-container-applications/microservices-addressability-service-registry.md b/docs/architecture/microservices/architect-microservice-container-applications/microservices-addressability-service-registry.md
index 9f1f1393b5c03..da2dec83c97a2 100644
--- a/docs/architecture/microservices/architect-microservice-container-applications/microservices-addressability-service-registry.md
+++ b/docs/architecture/microservices/architect-microservice-container-applications/microservices-addressability-service-registry.md
@@ -1,7 +1,7 @@
---
title: Microservices addressability and the service registry
description: Understand the role of the container image registries in the microservices architecture.
-ms.date: 01/13/2021
+ms.date: 11/19/2021
---
# Microservices addressability and the service registry
@@ -9,7 +9,7 @@ Each microservice has a unique name (URL) that's used to resolve its location. Y
The [service registry pattern](https://microservices.io/patterns/service-registry.html) is a key part of service discovery. The registry is a database containing the network locations of service instances. A service registry needs to be highly available and up-to-date. Clients could cache network locations obtained from the service registry. However, that information eventually goes out of date and clients can no longer discover service instances. So, a service registry consists of a cluster of servers that use a replication protocol to maintain consistency.
-In some microservice deployment environments (called clusters, to be covered in a later section), service discovery is built in. For example, an Azure Container Service with Kubernetes (AKS) environment can handle service instance registration and deregistration. It also runs a proxy on each cluster host that plays the role of server-side discovery router.
+In some microservice deployment environments (called clusters, to be covered in a later section), service discovery is built in. For example, an Azure Kubernetes Service (AKS) environment can handle service instance registration and deregistration. It also runs a proxy on each cluster host that plays the role of server-side discovery router.
## Additional resources
diff --git a/docs/architecture/microservices/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md b/docs/architecture/microservices/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md
index 41d1f40ef541a..357d29c4ae267 100644
--- a/docs/architecture/microservices/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md
+++ b/docs/architecture/microservices/architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md
@@ -1,7 +1,7 @@
---
title: Orchestrate microservices and multi-container applications for high scalability and availability
description: Discover the options to orchestrate microservices and multi-container applications for high scalability and availability and the possibilities of Azure Dev Spaces while developing Kubernetes application lifecycle.
-ms.date: 01/13/2021
+ms.date: 11/19/2021
---
# Orchestrate microservices and multi-container applications for high scalability and availability
@@ -33,6 +33,7 @@ The concepts of a cluster and a scheduler are closely related, so the products p
|:---:|---|
| **Kubernetes**
 | [*Kubernetes*](https://kubernetes.io/) is an open-source product that provides functionality that ranges from cluster infrastructure and container scheduling to orchestrating capabilities. It lets you automate deployment, scaling, and operations of application containers across clusters of hosts.
*Kubernetes* provides a container-centric infrastructure that groups application containers into logical units for easy management and discovery.
*Kubernetes* is mature in Linux, less mature in Windows. |
| **Azure Kubernetes Service (AKS)**
 | [AKS](https://azure.microsoft.com/services/kubernetes-service/) is a managed Kubernetes container orchestration service in Azure that simplifies Kubernetes cluster's management, deployment, and operations. |
+| **Azure Container Apps**
 | [Azure Container Apps](https://azure.microsoft.com/services/container-apps/) is a managed serverless container service for building and deploying modern apps at scale. |
## Using container-based orchestrators in Microsoft Azure
@@ -80,30 +81,6 @@ Helm is maintained by the [Cloud Native Computing Foundation (CNCF)](https://www
For more implementation information on Helm charts and Kubernetes, see the [Using Helm Charts to deploy eShopOnContainers to AKS](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Deploy-to-Azure-Kubernetes-Service-(AKS)) post.
-## Use Azure Dev Spaces for your Kubernetes application lifecycle
-
-[Azure Dev Spaces](/azure/dev-spaces/azure-dev-spaces) provides a rapid, iterative Kubernetes development experience for teams. With minimal dev machine setup, you can iteratively run and debug containers directly in Azure Kubernetes Service (AKS). Develop on Windows, Mac, or Linux using familiar tools like Visual Studio, Visual Studio Code, or the command line.
-
-As mentioned, Azure Dev Spaces uses Helm charts when deploying the container-based applications.
-
-Azure Dev Spaces helps development teams be more productive on Kubernetes because it allows you to rapidly iterate and debug code directly in a global Kubernetes cluster in Azure by using Visual Studio 2019 or Visual Studio Code. That Kubernetes cluster in Azure is a shared managed Kubernetes cluster, so your team can collaboratively work together. You can develop your code in isolation, then deploy to the global cluster and do end-to-end testing with other components without replicating or mocking up dependencies.
-
-As shown in figure 4-26, the most differential feature in Azure Dev Spaces is capability of creating 'spaces' that can run integrated to the rest of the global deployment in the cluster.
-
-
-
-**Figure 4-26**. Using multiple spaces in Azure Dev Spaces
-
-Basically you can set up a shared dev space in Azure. Each developer can focus on just their part of the application, and can iteratively develop pre-commit code in a dev space that already contains all the other services and cloud resources that their scenarios depend on. Dependencies are always up-to-date, and developers are working in a way that mirrors production.
-
-Azure Dev Spaces provides the concept of a space, which allows you to work in relative isolation, and without the fear of breaking your team's work. Each dev space is part of a hierarchical structure that allows you to override one microservice (or many), from the "top" master dev space, with your own work-in-progress microservice.
-
-This feature is based on URL prefixes, so when using any dev space prefix in the url, a request is served from the target microservice if it exists in the dev space, otherwise it's forwarded up to the first instance of the target microservice found in the hierarchy, eventually getting to the master dev space at the top.
-
-To get a practical view on a concrete example, see the [eShopOnContainers wiki page on Azure Dev Spaces](https://github.com/dotnet-architecture/eShopOnContainers/wiki/Azure-Dev-Spaces).
-
-For further information, check the article on [Team Development with Azure Dev Spaces](/azure/dev-spaces/team-development-netcore).
-
## Additional resources
- **Getting started with Azure Kubernetes Service (AKS)** \
diff --git a/docs/architecture/microservices/docker-application-development-process/docker-app-development-workflow.md b/docs/architecture/microservices/docker-application-development-process/docker-app-development-workflow.md
index fafe49dd7c4d1..17ab8f392c5d0 100644
--- a/docs/architecture/microservices/docker-application-development-process/docker-app-development-workflow.md
+++ b/docs/architecture/microservices/docker-application-development-process/docker-app-development-workflow.md
@@ -1,7 +1,7 @@
---
title: Development workflow for Docker apps
description: Understand the details of the workflow for developing Docker-based applications. Begin step by step and get into some details to optimize Dockerfiles and end with the simplified workflow available when using Visual Studio.
-ms.date: 02/02/2021
+ms.date: 11/19/2021
---
# Development workflow for Docker apps
@@ -31,7 +31,7 @@ In this section, this whole process is detailed and every major step is explaine
When you're using an editor/CLI development approach (for example, Visual Studio Code plus Docker CLI on macOS or Windows), you need to know every step, generally in more detail than if you're using Visual Studio. For more information about working in a CLI environment, see the e-book [Containerized Docker Application lifecycle with Microsoft Platforms and Tools](https://aka.ms/dockerlifecycleebook/).
-When you're using Visual Studio 2019, many of those steps are handled for you, which dramatically improves your productivity. This is especially true when you're using Visual Studio 2019 and targeting multi-container applications. For instance, with just one mouse click, Visual Studio adds the `Dockerfile` and `docker-compose.yml` file to your projects with the configuration for your application. When you run the application in Visual Studio, it builds the Docker image and runs the multi-container application directly in Docker; it even allows you to debug several containers at once. These features will boost your development speed.
+When you're using Visual Studio 2022, many of those steps are handled for you, which dramatically improves your productivity. This is especially true when you're using Visual Studio 2022 and targeting multi-container applications. For instance, with just one mouse click, Visual Studio adds the `Dockerfile` and `docker-compose.yml` file to your projects with the configuration for your application. When you run the application in Visual Studio, it builds the Docker image and runs the multi-container application directly in Docker; it even allows you to debug several containers at once. These features will boost your development speed.
However, just because Visual Studio makes those steps automatic doesn't mean that you don't need to know what's going on underneath with Docker. Therefore, the following guidance details every step.
@@ -43,25 +43,25 @@ Developing a Docker application is similar to the way you develop an application
### Set up your local environment with Visual Studio
-To begin, make sure you have [Docker Community Edition (CE)](https://docs.docker.com/docker-for-windows/) for Windows installed, as explained in the following instructions:
+To begin, make sure you have [Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/) for Windows installed, as explained in the following instructions:
-[Get started with Docker CE for Windows](https://docs.docker.com/docker-for-windows/)
+[Get started with Docker Desktop for Windows](https://docs.docker.com/docker-for-windows/)
-In addition, you need Visual Studio 2019 version 16.8, with the **.NET Core cross-platform development** workload installed, as shown in Figure 5-2.
+In addition, you need Visual Studio 2022 version 17.0, with the **.ASP.NET and web development** workload installed, as shown in Figure 5-2.
-**Figure 5-2**. Selecting the **.NET Core cross-platform development** workload during Visual Studio 2019 setup
+**Figure 5-2**. Selecting the **ASP.NET and web development** workload during Visual Studio 2022 setup
You can start coding your application in plain .NET (usually in .NET Core or later if you're planning to use containers) even before enabling Docker in your application and deploying and testing in Docker. However, it is recommended that you start working on Docker as soon as possible, because that will be the real environment and any issues can be discovered as soon as possible. This is encouraged because Visual Studio makes it so easy to work with Docker that it almost feels transparent—the best example when debugging multi-container applications from Visual Studio.
### Additional resources
-- **Get started with Docker CE for Windows** \
+- **Get started with Docker Desktop for Windows** \
-- **Visual Studio 2019** \
- [https://visualstudio.microsoft.com/downloads/](https://visualstudio.microsoft.com/downloads/?utm_medium=microsoft&utm_source=docs.microsoft.com&utm_campaign=inline+link&utm_content=download+vs2019)
+- **Visual Studio 2022** \
+ [https://visualstudio.microsoft.com/downloads/](https://visualstudio.microsoft.com/downloads/)
@@ -71,17 +71,17 @@ You need a Dockerfile for each custom image you want to build; you also need a D
The Dockerfile is placed in the root folder of your application or service. It contains the commands that tell Docker how to set up and run your application or service in a container. You can manually create a Dockerfile in code and add it to your project along with your .NET dependencies.
-With Visual Studio and its tools for Docker, this task requires only a few mouse clicks. When you create a new project in Visual Studio 2019, there's an option named **Enable Docker Support**, as shown in Figure 5-3.
+With Visual Studio and its tools for Docker, this task requires only a few mouse clicks. When you create a new project in Visual Studio 2022, there's an option named **Enable Docker Support**, as shown in Figure 5-3.
-**Figure 5-3**. Enabling Docker Support when creating a new ASP.NET Core project in Visual Studio 2019
+**Figure 5-3**. Enabling Docker Support when creating a new ASP.NET Core project in Visual Studio 2022
You can also enable Docker support on an existing ASP.NET Core web app project by right-clicking the project in **Solution Explorer** and selecting **Add** > **Docker Support...**, as shown in Figure 5-4.
-**Figure 5-4**. Enabling Docker support in an existing Visual Studio 2019 project
+**Figure 5-4**. Enabling Docker support in an existing Visual Studio 2022 project
This action adds a *Dockerfile* to the project with the required configuration, and is only available on ASP.NET Core projects.
@@ -91,14 +91,14 @@ In a similar fashion, Visual Studio can also add a `docker-compose.yml` file for
You usually build a custom image for your container on top of a base image you get from an official repository like the [Docker Hub](https://hub.docker.com/) registry. That is precisely what happens under the covers when you enable Docker support in Visual Studio. Your Dockerfile will use an existing `dotnet/core/aspnet` image.
-Earlier we explained which Docker images and repos you can use, depending on the framework and OS you have chosen. For instance, if you want to use ASP.NET Core (Linux or Windows), the image to use is `mcr.microsoft.com/dotnet/aspnet:5.0`. Therefore, you just need to specify what base Docker image you will use for your container. You do that by adding `FROM mcr.microsoft.com/dotnet/aspnet:5.0` to your Dockerfile. This will be automatically performed by Visual Studio, but if you were to update the version, you update this value.
+Earlier we explained which Docker images and repos you can use, depending on the framework and OS you have chosen. For instance, if you want to use ASP.NET Core (Linux or Windows), the image to use is `mcr.microsoft.com/dotnet/aspnet:6.0`. Therefore, you just need to specify what base Docker image you will use for your container. You do that by adding `FROM mcr.microsoft.com/dotnet/aspnet:6.0` to your Dockerfile. This will be automatically performed by Visual Studio, but if you were to update the version, you update this value.
Using an official .NET image repository from Docker Hub with a version number ensures that the same language features are available on all machines (including development, testing, and production).
The following example shows a sample Dockerfile for an ASP.NET Core container.
```dockerfile
-FROM mcr.microsoft.com/dotnet/aspnet:5.0
+FROM mcr.microsoft.com/dotnet/aspnet:6.0
ARG source
WORKDIR /app
EXPOSE 80
@@ -106,13 +106,13 @@ COPY ${source:-obj/Docker/publish} .
ENTRYPOINT ["dotnet", " MySingleContainerWebApp.dll "]
```
-In this case, the image is based on version 5.0 of the official ASP.NET Core Docker image (multi-arch for Linux and Windows). This is the setting `FROM mcr.microsoft.com/dotnet/aspnet:5.0`. (For more information about this base image, see the [ASP.NET Core Docker Image](https://hub.docker.com/_/microsoft-dotnet-aspnet/) page.) In the Dockerfile, you also need to instruct Docker to listen on the TCP port you will use at run time (in this case, port 80, as configured with the EXPOSE setting).
+In this case, the image is based on version 6.0 of the official ASP.NET Core Docker image (multi-arch for Linux and Windows). This is the setting `FROM mcr.microsoft.com/dotnet/aspnet:6.0`. (For more information about this base image, see the [ASP.NET Core Docker Image](https://hub.docker.com/_/microsoft-dotnet-aspnet/) page.) In the Dockerfile, you also need to instruct Docker to listen on the TCP port you will use at runtime (in this case, port 80, as configured with the EXPOSE setting).
You can specify additional configuration settings in the Dockerfile, depending on the language and framework you're using. For instance, the ENTRYPOINT line with `["dotnet", "MySingleContainerWebApp.dll"]` tells Docker to run a .NET application. If you're using the SDK and the .NET CLI (dotnet CLI) to build and run the .NET application, this setting would be different. The bottom line is that the ENTRYPOINT line and other settings will be different depending on the language and platform you choose for your application.
### Additional resources
-- **Building Docker Images for .NET 5 Applications** \
+- **Building Docker Images for .NET 6 Applications** \
[https://docs.microsoft.com/dotnet/core/docker/building-net-docker-images](/aspnet/core/host-and-deploy/docker/building-net-docker-images)
- **Build your own image**. In the official Docker documentation.\
@@ -130,16 +130,16 @@ A single repo can contain platform variants, such as a Linux image and a Windows
If you specify a tag, targeting a platform that is explicit like in the following cases:
-- `mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim` \
- Targets: .NET 5 runtime-only on Linux
+- `mcr.microsoft.com/dotnet/aspnet:6.0-buster-slim` \
+ Targets: .NET 6 runtime-only on Linux
-- `mcr.microsoft.com/dotnet/aspnet:5.0-nanoserver-1909` \
- Targets: .NET 5 runtime-only on Windows Nano Server
+- `mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1909` \
+ Targets: .NET 6 runtime-only on Windows Nano Server
But, if you specify the same image name, even with the same tag, the multi-arch images (like the `aspnet` image) will use the Linux or Windows version depending on the Docker host OS you're deploying, as shown in the following example:
-- `mcr.microsoft.com/dotnet/aspnet:5.0` \
- Multi-arch: .NET 5 runtime-only on Linux or Windows Nano Server depending on the Docker host OS
+- `mcr.microsoft.com/dotnet/aspnet:6.0` \
+ Multi-arch: .NET 6 runtime-only on Linux or Windows Nano Server depending on the Docker host OS
This way, when you pull an image from a Windows host, it will pull the Windows variant, and pulling the same image name from a Linux host will pull the Linux variant.
@@ -168,11 +168,11 @@ Probably the best way to understand multi-stage is going through a Dockerfile in
The initial Dockerfile might look something like this:
```dockerfile
- 1 FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
+ 1 FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
2 WORKDIR /app
3 EXPOSE 80
4
- 5 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS build
+ 5 FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
6 WORKDIR /src
7 COPY src/Services/Catalog/Catalog.API/Catalog.API.csproj …
8 COPY src/BuildingBlocks/HealthChecks/src/Microsoft.AspNetCore.HealthChecks …
@@ -271,11 +271,11 @@ For the final optimization, it just happens that line 20 is redundant, as line 2
The resulting file is then:
```dockerfile
- 1 FROM mcr.microsoft.com/dotnet/aspnet:5.0 AS base
+ 1 FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
2 WORKDIR /app
3 EXPOSE 80
4
- 5 FROM mcr.microsoft.com/dotnet/sdk:5.0 AS publish
+ 5 FROM mcr.microsoft.com/dotnet/sdk:6.0 AS publish
6 WORKDIR /src
7 COPY . .
8 RUN dotnet restore /ignoreprojectextensions:.dcproj
@@ -401,7 +401,7 @@ The docker-compose.yml file specifies not only what containers are being used, b
We will revisit the docker-compose.yml file in a later section when we cover how to implement microservices and multi-container apps.
-### Working with docker-compose.yml in Visual Studio 2019
+### Working with docker-compose.yml in Visual Studio 2022
Besides adding a Dockerfile to a project, as we mentioned before, Visual Studio 2017 (from version 15.8 on) can add orchestrator support for Docker Compose to a solution.
@@ -413,13 +413,13 @@ At the time of this writing, Visual Studio supports **Docker Compose** and **Kub
-**Figure 5-7**. Adding Docker support in Visual Studio 2019 by right-clicking an ASP.NET Core project
+**Figure 5-7**. Adding Docker support in Visual Studio 2022 by right-clicking an ASP.NET Core project
After you add orchestrator support to your solution in Visual Studio, you will also see a new node (in the `docker-compose.dcproj` project file) in Solution Explorer that contains the added docker-compose.yml files, as shown in Figure 5-8.
-**Figure 5-8**. The **docker-compose** tree node added in Visual Studio 2019 Solution Explorer
+**Figure 5-8**. The **docker-compose** tree node added in Visual Studio 2022 Solution Explorer
You could deploy a multi-container application with a single docker-compose.yml file by using the `docker-compose up` command. However, Visual Studio adds a group of them so you can override values depending on the environment (development or production) and execution type (release or debug). This capability will be explained in later sections.
@@ -485,7 +485,7 @@ The important point here is that, as shown in Figure 5-12, in Visual Studio 2019
-**Figure 5-12**. Running multi-container apps in Visual Studio 2019
+**Figure 5-12**. Running multi-container apps in Visual Studio 2022
### Additional resources
@@ -516,9 +516,9 @@ You can also test the application using curl from the terminal, as shown in Figu
**Figure 5-14**. Example of testing your Docker application locally using curl
-### Testing and debugging containers with Visual Studio 2019
+### Testing and debugging containers with Visual Studio 2022
-When running and debugging the containers with Visual Studio 2019, you can debug the .NET application in much the same way as you would when running without containers.
+When running and debugging the containers with Visual Studio 2022, you can debug the .NET application in much the same way as you would when running without containers.
### Testing and debugging without Visual Studio
@@ -526,12 +526,12 @@ If you're developing using the editor/CLI approach, debugging containers is more
### Additional resources
+- **Quickstart: Docker in Visual Studio.** \
+ [https://docs.microsoft.com/visualstudio/containers/container-tools?view=vs-2022](/visualstudio/containers/container-tools?view=vs-2022)
+
- **Debugging apps in a local Docker container** \
[https://docs.microsoft.com/visualstudio/containers/edit-and-refresh](/visualstudio/containers/edit-and-refresh)
-
-- **Steve Lasker. Build, Debug, Deploy ASP.NET Core Apps with Docker.** Video. \
-
-
+
## Simplified workflow when developing containers with Visual Studio
Effectively, the workflow when using Visual Studio is a lot simpler than if you use the editor/CLI approach. Most of the steps required by Docker related to the Dockerfile and docker-compose.yml files are hidden or simplified by Visual Studio, as shown in Figure 5-15.
@@ -546,7 +546,7 @@ In addition, you need to perform step 2 (adding Docker support to your projects)
### Additional resources
-- **Steve Lasker. .NET Docker Development with Visual Studio (2017)** \
+- **Debug apps in a local Docker container** \
## Using PowerShell commands in a Dockerfile to set up Windows Containers
diff --git a/docs/architecture/microservices/docker-application-development-process/index.md b/docs/architecture/microservices/docker-application-development-process/index.md
index 762b055a2b891..7866378220b2d 100644
--- a/docs/architecture/microservices/docker-application-development-process/index.md
+++ b/docs/architecture/microservices/docker-application-development-process/index.md
@@ -1,7 +1,7 @@
---
title: Development process for Docker-based applications
description: Get a high-level overview of the options for developing Docker-based applications. Using your choice of Visual Studio for Windows, Visual Studio for Mac, or Visual Studio Code for multiplatform support (Windows, macOS, and Linux).
-ms.date: 02/02/2021
+ms.date: 11/19/2021
---
# Development process for Docker-based applications
@@ -13,9 +13,9 @@ ms.date: 02/02/2021
Whether you prefer a full and powerful IDE or a lightweight and agile editor, Microsoft has tools that you can use for developing Docker applications.
-**Visual Studio (for Windows).** Docker-based .NET 5 application development with Visual Studio requires Visual Studio 2019 version 16.8 or later. Visual Studio 2019 comes with tools for Docker already built in. The tools for Docker let you develop, run, and validate your applications directly in the target Docker environment. You can press F5 to run and debug your application (single container or multiple containers) directly into a Docker host, or press CTRL+F5 to edit and refresh your application without having to rebuild the container. This IDE is the most powerful development choice for Docker-based apps.
+**Visual Studio (for Windows).** Docker-based .NET 6 application development with Visual Studio requires Visual Studio 2022 version 17.0 or later. Visual Studio 2022 comes with tools for Docker already built in. The tools for Docker let you develop, run, and validate your applications directly in the target Docker environment. You can press F5 to run and debug your application (single container or multiple containers) directly into a Docker host, or press CTRL + F5 to edit and refresh your application without having to rebuild the container. This IDE is the most powerful development choice for Docker-based apps.
-**Visual Studio for Mac.** It's an IDE, evolution of Xamarin Studio, running in macOS. For .NET 5 development, it requires version 8.4 or later. This tool should be the preferred choice for developers working in macOS machines who also want to use a powerful IDE.
+**Visual Studio for Mac.** It's an IDE, evolution of Xamarin Studio, running in macOS. For .NET 6 development, it requires version 8.4 or later. This tool should be the preferred choice for developers working in macOS machines who also want to use a powerful IDE.
**Visual Studio Code and Docker CLI**. If you prefer a lightweight and cross-platform editor that supports any development language, you can use Visual Studio Code and the Docker CLI. This IDE is a cross-platform development approach for macOS, Linux, and Windows. Additionally, Visual Studio Code supports extensions for Docker such as IntelliSense for Dockerfiles and shortcut tasks to run Docker commands from the editor.
@@ -37,7 +37,7 @@ By installing [Docker Desktop Community Edition (CE)](https://hub.docker.com/sea
## .NET languages and frameworks for Docker containers
-As mentioned in earlier sections of this guide, you can use .NET Framework, .NET 5, or the open-source Mono project when developing Docker containerized .NET applications. You can develop in C\#, F\#, or Visual Basic when targeting Linux or Windows Containers, depending on which .NET framework is in use. For more details about.NET languages, see the blog post [The .NET Language Strategy](https://devblogs.microsoft.com/dotnet/the-net-language-strategy/).
+As mentioned in earlier sections of this guide, you can use .NET Framework, .NET 6, or the open-source Mono project when developing Docker containerized .NET applications. You can develop in C\#, F\#, or Visual Basic when targeting Linux or Windows Containers, depending on which .NET framework is in use. For more details about.NET languages, see the blog post [The .NET Language Strategy](https://devblogs.microsoft.com/dotnet/the-net-language-strategy/).
>[!div class="step-by-step"]
>[Previous](../architect-microservice-container-applications/scalable-available-multi-container-microservice-applications.md)
diff --git a/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/dotnet-core-cross-platform-development.png b/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/dotnet-core-cross-platform-development.png
index f2cd353e355a8..5f5c31da408c2 100644
Binary files a/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/dotnet-core-cross-platform-development.png and b/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/dotnet-core-cross-platform-development.png differ
diff --git a/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/enable-docker-support-check-box.png b/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/enable-docker-support-check-box.png
index 0e685b54c1267..df906e71e8912 100644
Binary files a/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/enable-docker-support-check-box.png and b/docs/architecture/microservices/docker-application-development-process/media/docker-app-development-workflow/enable-docker-support-check-box.png differ
diff --git a/docs/architecture/microservices/implement-resilient-applications/implement-http-call-retries-exponential-backoff-polly.md b/docs/architecture/microservices/implement-resilient-applications/implement-http-call-retries-exponential-backoff-polly.md
index 610ea1155a1f8..bbf4771bb0442 100644
--- a/docs/architecture/microservices/implement-resilient-applications/implement-http-call-retries-exponential-backoff-polly.md
+++ b/docs/architecture/microservices/implement-resilient-applications/implement-http-call-retries-exponential-backoff-polly.md
@@ -12,9 +12,9 @@ Polly is a .NET library that provides resilience and transient-fault handling ca
The following steps show how you can use Http retries with Polly integrated into `IHttpClientFactory`, which is explained in the previous section.
-**Reference the .NET 5 packages**
+**Reference the .NET 6 packages**
-`IHttpClientFactory` is available since .NET Core 2.1 however we recommend you to use the latest .NET 5 packages from NuGet in your project. You typically also need to reference the extension package `Microsoft.Extensions.Http.Polly`.
+`IHttpClientFactory` is available since .NET Core 2.1 however we recommend you to use the latest .NET 6 packages from NuGet in your project. You typically also need to reference the extension package `Microsoft.Extensions.Http.Polly`.
**Configure a client with Polly's Retry policy, in Startup**
diff --git a/docs/architecture/microservices/implement-resilient-applications/monitor-app-health.md b/docs/architecture/microservices/implement-resilient-applications/monitor-app-health.md
index 4e3380382ad09..fa464c40c3e60 100644
--- a/docs/architecture/microservices/implement-resilient-applications/monitor-app-health.md
+++ b/docs/architecture/microservices/implement-resilient-applications/monitor-app-health.md
@@ -25,10 +25,10 @@ In this section, you'll learn how to implement the HealthChecks feature in a sam
To begin, you need to define what constitutes a healthy status for each microservice. In the sample application, we define the microservice is healthy if its API is accessible via HTTP and its related SQL Server database is also available.
-In .NET 5, with the built-in APIs, you can configure the services, add a Health Check for the microservice and its dependent SQL Server database in this way:
+In .NET 6, with the built-in APIs, you can configure the services, add a Health Check for the microservice and its dependent SQL Server database in this way:
```csharp
-// Startup.cs from .NET 5 Web API sample
+// Startup.cs from .NET 6 Web API sample
//
public void ConfigureServices(IServiceCollection services)
{
@@ -103,7 +103,7 @@ Note that in the previous code, `Select 1` is the query used to check the Health
Finally, add a middleware that responds to the url path `/hc`:
```csharp
-// Startup.cs from .NET 5 Web Api sample
+// Startup.cs from .NET 6 Web Api sample
//
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
@@ -124,7 +124,7 @@ When the endpoint `/hc` is invoked, it runs all the health che
Microservices in eShopOnContainers rely on multiple services to perform its task. For example, the `Catalog.API` microservice from eShopOnContainers depends on many services, such as Azure Blob Storage, SQL Server, and RabbitMQ. Therefore, it has several health checks added using the `AddCheck()` method. For every dependent service, a custom `IHealthCheck` implementation that defines its respective health status would need to be added.
-The open-source project [AspNetCore.Diagnostics.HealthChecks](https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks) solves this problem by providing custom health check implementations for each of these enterprise services, that are built on top of .NET 5. Each health check is available as an individual NuGet package that can be easily added to the project. eShopOnContainers uses them extensively in all its microservices.
+The open-source project [AspNetCore.Diagnostics.HealthChecks](https://github.com/Xabaril/AspNetCore.Diagnostics.HealthChecks) solves this problem by providing custom health check implementations for each of these enterprise services, that are built on top of .NET 6. Each health check is available as an individual NuGet package that can be easily added to the project. eShopOnContainers uses them extensively in all its microservices.
For instance, in the `Catalog.API` microservice, the following NuGet packages were added:
diff --git a/docs/architecture/microservices/index.md b/docs/architecture/microservices/index.md
index b3558fa7c3617..798068f4be313 100644
--- a/docs/architecture/microservices/index.md
+++ b/docs/architecture/microservices/index.md
@@ -1,13 +1,13 @@
---
title: .NET Microservices. Architecture for Containerized .NET Applications
description: .NET Microservices Architecture for Containerized .NET Applications | Microservices are modular and independently deployable services. Docker containers (for Linux and Windows) simplify deployment and testing by bundling a service and its dependencies into a single unit, which is then run in an isolated environment.
-ms.date: 02/02/2021
+ms.date: 11/19/2021
---
# .NET Microservices: Architecture for Containerized .NET Applications
-**EDITION v5.0** - Updated to ASP.NET Core 5.0
+**EDITION v6.0** - Updated to ASP.NET Core 6.0
Refer [changelog](https://aka.ms/MicroservicesEbookChangelog) for the book updates and community contributions.
@@ -43,7 +43,7 @@ After you have studied this guide, your next step would be to learn about produc
## Version
-This guide has been revised to cover **.NET 5** version along with many additional updates related to the same “wave” of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET 5 release. That’s why the book version has also been updated to version **5.0**.
+This guide has been revised to cover **.NET 6** version along with many additional updates related to the same "wave" of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET 6 release. That’s why the book version has also been updated to version **6.0**.
## What this guide does not cover
@@ -62,7 +62,7 @@ You will also find this guide useful if you are a technical decision maker, such
### How to use this guide
-The first part of this guide introduces Docker containers, discusses how to choose between .NET 5 and the .NET Framework as a development framework, and provides an overview of microservices. This content is for architects and technical decision makers who want an overview but don't need to focus on code implementation details.
+The first part of this guide introduces Docker containers, discusses how to choose between .NET 6 and the .NET Framework as a development framework, and provides an overview of microservices. This content is for architects and technical decision makers who want an overview but don't need to focus on code implementation details.
The second part of the guide starts with the [Development process for Docker based applications](./docker-application-development-process/index.md) section. It focuses on the development and microservice patterns for implementing applications using .NET and Docker. This section will be of most interest to developers and architects who want to focus on code and on patterns and implementation details.
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 fc5c4f1d587e9..7033e825cdee8 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
@@ -1,7 +1,7 @@
---
title: Defining your multi-container application with docker-compose.yml
description: How to specify microservices composition for a multicontainer application with docker-compose.yml.
-ms.date: 06/23/2021
+ms.date: 11/19/2021
---
# Defining your multi-container application with docker-compose.yml
@@ -245,7 +245,7 @@ services:
- marketing-api
sqldata:
- image: mcr.microsoft.com/mssql/server:2017-latest
+ image: mcr.microsoft.com/mssql/server:2019-latest
nosqldata:
image: mongo
@@ -432,7 +432,7 @@ The values set in the run-time environment always override the values defined in
If you are exploring Docker and .NET on sources on the Internet, you will find Dockerfiles that demonstrate the simplicity of building a Docker image by copying your source into a container. These examples suggest that by using a simple configuration, you can have a Docker image with the environment packaged with your application. The following example shows a simple Dockerfile in this vein.
```dockerfile
-FROM mcr.microsoft.com/dotnet/sdk:5.0
+FROM mcr.microsoft.com/dotnet/sdk:6.0
WORKDIR /app
ENV ASPNETCORE_URLS http://+:80
EXPOSE 80
diff --git a/docs/architecture/microservices/net-core-net-framework-containers/container-framework-choice-factors.md b/docs/architecture/microservices/net-core-net-framework-containers/container-framework-choice-factors.md
index ec801353d6037..563fd4f0c13eb 100644
--- a/docs/architecture/microservices/net-core-net-framework-containers/container-framework-choice-factors.md
+++ b/docs/architecture/microservices/net-core-net-framework-containers/container-framework-choice-factors.md
@@ -1,27 +1,27 @@
---
title: Decision table. .NET frameworks to use for Docker
description: .NET Microservices Architecture for Containerized .NET Applications | Decision table, .NET frameworks to use for Docker
-ms.date: 01/13/2021
+ms.date: 11/19/2021
---
# Decision table: .NET frameworks to use for Docker
-The following decision table summarizes whether to use .NET Framework or .NET 5. Remember that for Linux containers, you need Linux-based Docker hosts (VMs or servers) and that for Windows Containers you need Windows Server based Docker hosts (VMs or servers).
+The following decision table summarizes whether to use .NET Framework or .NET 6. Remember that for Linux containers, you need Linux-based Docker hosts (VMs or servers) and that for Windows Containers you need Windows Server based Docker hosts (VMs or servers).
> [!IMPORTANT]
> Your development machines will run one Docker host, either Linux or Windows. Related microservices that you want to run and test together in one solution will all need to run on the same container platform.
| Architecture / App Type | Linux containers | Windows Containers |
|-------------------------|------------------|--------------------|
-| Microservices on containers | .NET 5 | .NET 5 |
-| Monolithic app | .NET 5 | .NET Framework
.NET 5 |
-| Best-in-class performance and scalability | .NET 5 | .NET 5 |
+| Microservices on containers | .NET 6 | .NET 6 |
+| Monolithic app | .NET 6 | .NET Framework
.NET 6 |
+| Best-in-class performance and scalability | .NET 6 | .NET 6 |
| Windows Server legacy app ("brown-field") migration to containers | -- | .NET Framework |
-| New container-based development ("green-field") | .NET 5 | .NET 5 |
-| ASP.NET Core | .NET 5 | .NET 5 (recommended)
.NET Framework |
+| New container-based development ("green-field") | .NET 6 | .NET 6 |
+| ASP.NET Core | .NET 6 | .NET 6 (recommended)
.NET Framework |
| ASP.NET 4 (MVC 5, Web API 2, and Web Forms) | -- | .NET Framework |
| SignalR services | .NET Core 2.1 or higher version | .NET Framework
.NET Core 2.1 or higher version |
-| WCF, WF, and other legacy frameworks | WCF in .NET Core (client library only) | .NET Framework
WCF in .NET 5 (client library only) |
-| Consumption of Azure services | .NET 5
(eventually most Azure services will provide client SDKs for .NET 5) | .NET Framework
.NET 5
(eventually most Azure services will provide client SDKs for .NET 5) |
+| WCF, WF, and other legacy frameworks | WCF in .NET Core (client library only) | .NET Framework
WCF in .NET 6 (client library only) |
+| Consumption of Azure services | .NET 6
(eventually most Azure services will provide client SDKs for .NET 6) | .NET Framework
.NET 6
(eventually most Azure services will provide client SDKs for .NET 6) |
>[!div class="step-by-step"]
>[Previous](net-framework-container-scenarios.md)
diff --git a/docs/architecture/microservices/net-core-net-framework-containers/general-guidance.md b/docs/architecture/microservices/net-core-net-framework-containers/general-guidance.md
index 4c43e5b408dc6..ee04da94687d2 100644
--- a/docs/architecture/microservices/net-core-net-framework-containers/general-guidance.md
+++ b/docs/architecture/microservices/net-core-net-framework-containers/general-guidance.md
@@ -1,13 +1,13 @@
---
title: General guidance
description: .NET Microservices Architecture for Containerized .NET Applications | General guidance
-ms.date: 01/13/2021
+ms.date: 11/19/2021
---
# General guidance
-This section provides a summary of when to choose .NET 5 or .NET Framework. We provide more details about these choices in the sections that follow.
+This section provides a summary of when to choose .NET 6 or .NET Framework. We provide more details about these choices in the sections that follow.
-Use .NET 5, with Linux or Windows Containers, for your containerized Docker server application when:
+Use .NET 6, with Linux or Windows Containers, for your containerized Docker server application when:
- You have cross-platform needs. For example, you want to use both Linux and Windows Containers.
@@ -15,17 +15,17 @@ Use .NET 5, with Linux or Windows Containers, for your containerized Docker serv
- You need to start containers fast and want a small footprint per container to achieve better density or more containers per hardware unit in order to lower your costs.
-In short, when you create new containerized .NET applications, you should consider .NET 5 as the default choice. It has many benefits and fits best with the containers philosophy and style of working.
+In short, when you create new containerized .NET applications, you should consider .NET 6 as the default choice. It has many benefits and fits best with the containers philosophy and style of working.
-An extra benefit of using .NET 5 is that you can run side-by-side .NET versions for applications within the same machine. This benefit is more important for servers or VMs that do not use containers, because containers isolate the versions of .NET that the app needs. (As long as they are compatible with the underlying OS.)
+An extra benefit of using .NET 6 is that you can run side-by-side .NET versions for applications within the same machine. This benefit is more important for servers or VMs that do not use containers, because containers isolate the versions of .NET that the app needs. (As long as they are compatible with the underlying OS.)
Use .NET Framework for your containerized Docker server application when:
- Your application currently uses .NET Framework and has strong dependencies on Windows.
-- You need to use Windows APIs that are not supported by .NET 5.
+- You need to use Windows APIs that are not supported by .NET 6.
-- You need to use third-party .NET libraries or NuGet packages that are not available for .NET 5.
+- You need to use third-party .NET libraries or NuGet packages that are not available for .NET 6.
Using .NET Framework on Docker can improve your deployment experiences by minimizing deployment issues. This ["lift and shift" scenario](https://aka.ms/liftandshiftwithcontainersebook) is important for containerizing legacy applications that were originally developed with the traditional .NET Framework, like ASP.NET WebForms, MVC web apps or WCF (Windows Communication Foundation) services.
diff --git a/docs/architecture/microservices/net-core-net-framework-containers/index.md b/docs/architecture/microservices/net-core-net-framework-containers/index.md
index 83ebabc5adc5d..90e5a475ccdd4 100644
--- a/docs/architecture/microservices/net-core-net-framework-containers/index.md
+++ b/docs/architecture/microservices/net-core-net-framework-containers/index.md
@@ -1,11 +1,11 @@
---
-title: Choosing Between .NET 5 and .NET Framework for Docker Containers
-description: .NET Microservices Architecture for Containerized .NET Applications | Choosing Between .NET 5 and .NET Framework for Docker Containers
-ms.date: 02/02/2021
+title: Choosing Between .NET 6 and .NET Framework for Docker Containers
+description: .NET Microservices Architecture for Containerized .NET Applications | Choosing Between .NET 6 and .NET Framework for Docker Containers
+ms.date: 11/19/2021
---
-# Choosing Between .NET 5 and .NET Framework for Docker Containers
+# Choosing Between .NET 6 and .NET Framework for Docker Containers
-There are two supported frameworks for building server-side containerized Docker applications with .NET: [.NET Framework and .NET 5](https://dotnet.microsoft.com/download). They share many .NET platform components, and you can share code across the two. However, there are fundamental differences between them, and which framework you use will depend on what you want to accomplish. This section provides guidance on when to choose each framework.
+There are two supported frameworks for building server-side containerized Docker applications with .NET: [.NET Framework and .NET 6](https://dotnet.microsoft.com/download). They share many .NET platform components, and you can share code across the two. However, there are fundamental differences between them, and which framework you use will depend on what you want to accomplish. This section provides guidance on when to choose each framework.
>[!div class="step-by-step"]
>[Previous](../container-docker-introduction/docker-containers-images-registries.md)
diff --git a/docs/architecture/microservices/net-core-net-framework-containers/net-container-os-targets.md b/docs/architecture/microservices/net-core-net-framework-containers/net-container-os-targets.md
index b98067ff06092..627ff035fb54d 100644
--- a/docs/architecture/microservices/net-core-net-framework-containers/net-container-os-targets.md
+++ b/docs/architecture/microservices/net-core-net-framework-containers/net-container-os-targets.md
@@ -6,9 +6,9 @@ ms.date: 01/13/2021
# What OS to target with .NET containers
-Given the diversity of operating systems supported by Docker and the differences between .NET Framework and .NET 5, you should target a specific OS and specific versions depending on the framework you are using.
+Given the diversity of operating systems supported by Docker and the differences between .NET Framework and .NET 6, you should target a specific OS and specific versions depending on the framework you are using.
-For Windows, you can use Windows Server Core or Windows Nano Server. These Windows versions provide different characteristics (IIS in Windows Server Core versus a self-hosted web server like Kestrel in Nano Server) that might be needed by .NET Framework or .NET 5, respectively.
+For Windows, you can use Windows Server Core or Windows Nano Server. These Windows versions provide different characteristics (IIS in Windows Server Core versus a self-hosted web server like Kestrel in Nano Server) that might be needed by .NET Framework or .NET 6, respectively.
For Linux, multiple distros are available and supported in official .NET Docker images (like Debian).
@@ -18,7 +18,7 @@ In Figure 3-1, you can see the possible OS version depending on the .NET framewo
**Figure 3-1.** Operating systems to target depending on versions of the .NET framework
-When deploying legacy .NET Framework applications you have to target Windows Server Core, compatible with legacy apps and IIS, but it has a larger image. When deploying .NET 5 applications, you can target Windows Nano Server, which is cloud optimized, uses Kestrel and is smaller and starts faster. You can also target Linux, supporting Debian, Alpine, and others. Also uses Kestrel, is smaller, and starts faster.
+When deploying legacy .NET Framework applications you have to target Windows Server Core, compatible with legacy apps and IIS, but it has a larger image. When deploying .NET 6 applications, you can target Windows Nano Server, which is cloud optimized, uses Kestrel and is smaller and starts faster. You can also target Linux, supporting Debian, Alpine, and others. Also uses Kestrel, is smaller, and starts faster.
You can also create your own Docker image in cases where you want to use a different Linux distro or where you want an image with versions not provided by Microsoft. For example, you might create an image with ASP.NET Core running on the traditional .NET Framework and Windows Server Core, which is a not-so-common scenario for Docker.
@@ -26,10 +26,10 @@ When you add the image name to your Dockerfile file, you can select the operatin
| Image | Comments |
|-------|----------|
-| mcr.microsoft.com/dotnet/runtime:5.0 | .NET 5 multi-architecture: Supports Linux and Windows Nano Server depending on the Docker host. |
-| mcr.microsoft.com/dotnet/aspnet:5.0 | ASP.NET Core 5.0 multi-architecture: Supports Linux and Windows Nano Server depending on the Docker host.
The aspnetcore image has a few optimizations for ASP.NET Core. |
-| mcr.microsoft.com/dotnet/aspnet:5.0-buster-slim | .NET 5 runtime-only on Linux Debian distro |
-| mcr.microsoft.com/dotnet/aspnet:5.0-nanoserver-1809 | .NET 5 runtime-only on Windows Nano Server (Windows Server version 1809) |
+| mcr.microsoft.com/dotnet/runtime:6.0 | .NET 6 multi-architecture: Supports Linux and Windows Nano Server depending on the Docker host. |
+| mcr.microsoft.com/dotnet/aspnet:6.0 | ASP.NET Core 6.0 multi-architecture: Supports Linux and Windows Nano Server depending on the Docker host.
The aspnetcore image has a few optimizations for ASP.NET Core. |
+| mcr.microsoft.com/dotnet/aspnet:6.0-buster-slim | .NET 6 runtime-only on Linux Debian distro |
+| mcr.microsoft.com/dotnet/aspnet:6.0-nanoserver-1809 | .NET 6 runtime-only on Windows Nano Server (Windows Server version 1809) |
> [!div class="step-by-step"]
> [Previous](container-framework-choice-factors.md)
diff --git a/docs/architecture/microservices/net-core-net-framework-containers/net-core-container-scenarios.md b/docs/architecture/microservices/net-core-net-framework-containers/net-core-container-scenarios.md
index 700632f3b3ad7..5edd1547d9756 100644
--- a/docs/architecture/microservices/net-core-net-framework-containers/net-core-container-scenarios.md
+++ b/docs/architecture/microservices/net-core-net-framework-containers/net-core-container-scenarios.md
@@ -1,47 +1,47 @@
---
-title: When to choose .NET 5 for Docker containers
+title: When to choose .NET 6 for Docker containers
description: .NET Microservices Architecture for Containerized .NET Applications | When to choose .NET for Docker containers
-ms.date: 02/02/2021
+ms.date: 11/19/2021
---
# When to choose .NET for Docker containers
-The modularity and lightweight nature of .NET 5 makes it perfect for containers. When you deploy and start a container, its image is far smaller with .NET 5 than with .NET Framework. In contrast, to use .NET Framework for a container, you must base your image on the Windows Server Core image, which is a lot heavier than the Windows Nano Server or Linux images that you use for .NET 5.
+The modularity and lightweight nature of .NET 6 makes it perfect for containers. When you deploy and start a container, its image is far smaller with .NET 6 than with .NET Framework. In contrast, to use .NET Framework for a container, you must base your image on the Windows Server Core image, which is a lot heavier than the Windows Nano Server or Linux images that you use for .NET 6.
-Additionally, .NET 5 is cross-platform, so you can deploy server apps with Linux or Windows container images. However, if you are using the traditional .NET Framework, you can only deploy images based on Windows Server Core.
+Additionally, .NET 6 is cross-platform, so you can deploy server apps with Linux or Windows container images. However, if you are using the traditional .NET Framework, you can only deploy images based on Windows Server Core.
-The following is a more detailed explanation of why to choose .NET 5.
+The following is a more detailed explanation of why to choose .NET 6.
## Developing and deploying cross platform
-Clearly, if your goal is to have an application (web app or service) that can run on multiple platforms supported by Docker (Linux and Windows), the right choice is .NET 5, because .NET Framework only supports Windows.
+Clearly, if your goal is to have an application (web app or service) that can run on multiple platforms supported by Docker (Linux and Windows), the right choice is .NET 6, because .NET Framework only supports Windows.
-.NET 5 also supports macOS as a development platform. However, when you deploy containers to a Docker host, that host must (currently) be based on Linux or Windows. For example, in a development environment, you could use a Linux VM running on a Mac.
+.NET 6 also supports macOS as a development platform. However, when you deploy containers to a Docker host, that host must (currently) be based on Linux or Windows. For example, in a development environment, you could use a Linux VM running on a Mac.
[Visual Studio](https://www.visualstudio.com/vs/) provides an integrated development environment (IDE) for Windows and supports Docker development.
[Visual Studio for Mac](https://www.visualstudio.com/vs/visual-studio-mac/) is an IDE, evolution of Xamarin Studio, that runs on macOS and supports Docker-based application development. This tool should be the preferred choice for developers working in Mac machines who also want to use a powerful IDE.
-You can also use [Visual Studio Code](https://code.visualstudio.com/) on macOS, Linux, and Windows. Visual Studio Code fully supports .NET 5, including IntelliSense and debugging. Because VS Code is a lightweight editor, you can use it to develop containerized apps on the machine in conjunction with the Docker CLI and the [.NET CLI](../../../core/tools/index.md). You can also target .NET 5 with most third-party editors like Sublime, Emacs, vi, and the open-source OmniSharp project, which also provides IntelliSense support.
+You can also use [Visual Studio Code](https://code.visualstudio.com/) on macOS, Linux, and Windows. Visual Studio Code fully supports .NET 6, including IntelliSense and debugging. Because VS Code is a lightweight editor, you can use it to develop containerized apps on the machine in conjunction with the Docker CLI and the [.NET CLI](../../../core/tools/index.md). You can also target .NET 6 with most third-party editors like Sublime, Emacs, vi, and the open-source OmniSharp project, which also provides IntelliSense support.
In addition to the IDEs and editors, you can use the [.NET CLI](../../../core/tools/index.md) for all supported platforms.
## Using containers for new ("green-field") projects
-Containers are commonly used in conjunction with a microservices architecture, although they can also be used to containerize web apps or services that follow any architectural pattern. You can use .NET Framework on Windows Containers, but the modularity and lightweight nature of .NET 5 makes it perfect for containers and microservices architectures. When you create and deploy a container, its image is far smaller with .NET 5 than with .NET Framework.
+Containers are commonly used in conjunction with a microservices architecture, although they can also be used to containerize web apps or services that follow any architectural pattern. You can use .NET Framework on Windows Containers, but the modularity and lightweight nature of .NET 6 makes it perfect for containers and microservices architectures. When you create and deploy a container, its image is far smaller with .NET 6 than with .NET Framework.
## Create and deploy microservices on containers
You could use the traditional .NET Framework for building microservices-based applications (without containers) by using plain processes. That way, because the .NET Framework is already installed and shared across processes, processes are light and fast to start. However, if you are using containers, the image for the traditional .NET Framework is also based on Windows Server Core and that makes it too heavy for a microservices-on-containers approach. However, teams have been looking for opportunities to improve the experience for .NET Framework users as well. Recently, size of the [Windows Server Core container images have been reduced to >40% smaller](https://devblogs.microsoft.com/dotnet/we-made-windows-server-core-container-images-40-smaller).
-On the other hand, .NET 5 is the best candidate if you're embracing a microservices-oriented system that is based on containers, because .NET 5 is lightweight. In addition, its related container images, for either Linux or Windows Nano Server, are lean and small, making containers light and fast to start.
+On the other hand, .NET 6 is the best candidate if you're embracing a microservices-oriented system that is based on containers because .NET 6 is lightweight. In addition, its related container images, for either Linux or Windows Nano Server, are lean and small, making containers light and fast to start.
-A microservice is meant to be as small as possible: to be light when spinning up, to have a small footprint, to have a small Bounded Context (check DDD, [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design)), to represent a small area of concerns, and to be able to start and stop fast. For those requirements, you will want to use small and fast-to-instantiate container images like the .NET 5 container image.
+A microservice is meant to be as small as possible: to be light when spinning up, to have a small footprint, to have a small Bounded Context (check DDD, [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design)), to represent a small area of concerns, and to be able to start and stop fast. For those requirements, you will want to use small and fast-to-instantiate container images like the .NET 6 container image.
-A microservices architecture also allows you to mix technologies across a service boundary. This approach enables a gradual migration to .NET 5 for new microservices that work in conjunction with other microservices or with services developed with Node.js, Python, Java, GoLang, or other technologies.
+A microservices architecture also allows you to mix technologies across a service boundary. This approach enables a gradual migration to .NET 6 for new microservices that work in conjunction with other microservices or with services developed with Node.js, Python, Java, GoLang, or other technologies.
## Deploying high density in scalable systems
-When your container-based system needs the best possible density, granularity, and performance, .NET and ASP.NET Core are your best options. ASP.NET Core is up to 10 times faster than ASP.NET in the traditional .NET Framework, and it leads other popular industry technologies for microservices, such as Java servlets, Go, and Node.js.
+When your container-based system needs the best possible density, granularity, and performance, .NET and ASP.NET Core are your best options. ASP.NET Core is up to 10 times faster than ASP.NET in the traditional .NET Framework, and it leads to other popular industry technologies for microservices, such as Java servlets, Go, and Node.js.
This approach is especially relevant for microservices architectures, where you could have hundreds of microservices (containers) running. With ASP.NET Core images (based on the .NET runtime) on Linux or Windows Nano, you can run your system with a much lower number of servers or VMs, ultimately saving costs in infrastructure and hosting.
diff --git a/docs/architecture/microservices/net-core-net-framework-containers/net-framework-container-scenarios.md b/docs/architecture/microservices/net-core-net-framework-containers/net-framework-container-scenarios.md
index 112e80c22d8fd..983d726574b0c 100644
--- a/docs/architecture/microservices/net-core-net-framework-containers/net-framework-container-scenarios.md
+++ b/docs/architecture/microservices/net-core-net-framework-containers/net-framework-container-scenarios.md
@@ -1,60 +1,61 @@
---
title: When to choose .NET Framework for Docker containers
description: .NET Microservices Architecture for Containerized .NET Applications | When to choose .NET Framework for Docker containers
-ms.date: 01/13/2021
+ms.date: 11/19/2021
---
# When to choose .NET Framework for Docker containers
-While .NET 5 offers significant benefits for new applications and application patterns, .NET Framework will continue to be a good choice for many existing scenarios.
+While .NET 6 offers significant benefits for new applications and application patterns, .NET Framework will continue to be a good choice for many existing scenarios.
## Migrating existing applications directly to a Windows Server container
You might want to use Docker containers just to simplify deployment, even if you are not creating microservices. For example, perhaps you want to improve your DevOps workflow with Docker—containers can give you better isolated test environments and can also eliminate deployment issues caused by missing dependencies when you move to a production environment. In cases like these, even if you are deploying a monolithic application, it makes sense to use Docker and Windows Containers for your current .NET Framework applications.
-In most cases for this scenario, you will not need to migrate your existing applications to .NET 5; you can use Docker containers that include the traditional .NET Framework. However, a recommended approach is to use .NET 5 as you extend an existing application, such as writing a new service in ASP.NET Core.
+In most cases for this scenario, you will not need to migrate your existing applications to .NET 6; you can use Docker containers that include the traditional .NET Framework. However, a recommended approach is to use .NET 6 as you extend an existing application, such as writing a new service in ASP.NET Core.
-## Using third-party .NET libraries or NuGet packages not available for .NET 5
+## Using third-party .NET libraries or NuGet packages not available for .NET 6
-Third-party libraries are quickly embracing [.NET Standard](../../../standard/net-standard.md), which enables code sharing across all .NET flavors, including .NET 5. With .NET Standard 2.0 and later, the API surface compatibility across different frameworks has become significantly larger. Even more, .NET Core 2.x and newer applications can also directly reference existing .NET Framework libraries (see [.NET Framework 4.6.1 supporting .NET Standard 2.0](https://github.com/dotnet/standard/blob/master/docs/planning/netstandard-2.0/README.md#net-framework-461-supporting-net-standard-20)).
+Third-party libraries are quickly embracing [.NET Standard](../../../standard/net-standard.md), which enables code sharing across all .NET flavors, including .NET 6. With .NET Standard 2.0 and later, the API surface compatibility across different frameworks has become significantly larger. Even more, .NET Core 2.x and newer applications can also directly reference existing .NET Framework libraries (see [.NET Framework 4.6.1 supporting .NET Standard 2.0](https://github.com/dotnet/standard/blob/master/docs/planning/netstandard-2.0/README.md#net-framework-461-supporting-net-standard-20)).
In addition, the [Windows Compatibility Pack](../../../core/porting/windows-compat-pack.md) extends the API surface available for .NET Standard 2.0 on Windows. This pack allows recompiling most existing code to .NET Standard 2.x with little or no modification, to run on Windows.
However, even with that exceptional progression since .NET Standard 2.0 and .NET Core 2.1 or later, there might be cases where certain NuGet packages need Windows to run and might not support .NET Core or later. If those packages are critical for your application, then you will need to use .NET Framework on Windows Containers.
-## Using .NET technologies not available for .NET 5
+## Using .NET technologies not available for .NET 6
Some .NET Framework technologies aren't available in the current version of .NET (version 5.0 as of this writing). Some of them might become available in later releases, but others don't fit the new application patterns targeted by .NET Core and might never be available.
-The following list shows most of the technologies that aren't available in .NET 5:
+The following list shows most of the technologies that aren't available in .NET 6:
- ASP.NET Web Forms. This technology is only available on .NET Framework. Currently there are no plans to bring ASP.NET Web Forms to .NET or later.
-- WCF services. Even when a [WCF-Client library](https://github.com/dotnet/wcf) is available to consume WCF services from .NET 5, as of Jan-2021, the WCF server implementation is only available on .NET Framework.
+- WCF services. Even when a [WCF-Client library](https://github.com/dotnet/wcf) is available to consume WCF services from .NET 6, as of Jan-2021, the WCF server implementation is only available on .NET Framework.
-- Workflow-related services. Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service), and WCF Data Services (formerly known as ADO.NET Data Services) are only available on .NET Framework. There are currently no plans to bring them to .NET 5.
+- Workflow-related services. Windows Workflow Foundation (WF), Workflow Services (WCF + WF in a single service), and WCF Data Services (formerly known as ADO.NET Data Services) are only available on .NET Framework. There are currently no plans to bring them to .NET 6.
In addition to the technologies listed in the official [.NET roadmap](https://github.com/dotnet/core/blob/main/roadmap.md), other features might be ported to the new [unified .NET platform](https://devblogs.microsoft.com/dotnet/introducing-net-5/). You might consider participating in the discussions on GitHub so that your voice can be heard. And if you think something is missing, file a new issue in the [dotnet/runtime](https://github.com/dotnet/runtime/issues/new) GitHub repository.
-## Using a platform or API that doesn't support .NET 5
+## Using a platform or API that doesn't support .NET 6
-Some Microsoft and third-party platforms don't support .NET 5. For example, some Azure services provide an SDK that isn't yet available for consumption on .NET 5. Most Azure SDK should eventually be ported to .NET 5/Standard but some might not for various reasons. You can see the available Azure SDKs in the [Azure SDK Latest Releases](https://azure.github.io/azure-sdk/releases/latest/index.html) page.
+Some Microsoft and third-party platforms don't support .NET 6. For example, some Azure services provide an SDK that isn't yet available for consumption on .NET 6 yet. Most Azure SDK should eventually be ported to .NET 6/.NET Standard, but some might not for several reasons. You can see the available Azure SDKs in the [Azure SDK Latest Releases](https://azure.github.io/azure-sdk/releases/latest/index.html) page.
-In the meantime, if any platform or service in Azure still doesn't support .NET 5 with its client API, you can use the equivalent REST API from the Azure service or the client SDK on .NET Framework.
+In the meantime, if any platform or service in Azure still doesn't support .NET 6 with its client API, you can use the equivalent REST API from the Azure service or the client SDK on .NET Framework.
+
+## Porting existing ASP.NET application to .NET 6
+
+.NET Core is a revolutionary step forward from .NET Framework. It offers a host of advantages over .NET Framework across the board from productivity to performance, from cross-platform support to developer satisfaction. If you are using .NET Framework and planning to migrate your application to .NET Core and later to .NET 6, then refer to this guide [Porting Existing ASP.NET Apps to .NET Core](https://docs.microsoft.com/dotnet/architecture/porting-existing-aspnet-apps/).
### Additional resources
- **.NET fundamentals** \
[https://docs.microsoft.com/dotnet/fundamentals](../../../fundamentals/index.yml)
-
-- **Porting Projects to .NET 5** \
- [https://channel9.msdn.com/Events/dotnetConf/2020/Porting-Projects-to-NET-5](https://channel9.msdn.com/Events/dotnetConf/2020/Porting-Projects-to-NET-5)
-
+
- **.NET on Docker Guide** \
[https://docs.microsoft.com/dotnet/core/docker/introduction](../../../core/docker/introduction.md)
- **.NET Components Overview** \
[https://docs.microsoft.com/dotnet/standard/components](../../../standard/components.md)
-
+
>[!div class="step-by-step"]
>[Previous](net-core-container-scenarios.md)
>[Next](container-framework-choice-factors.md)
diff --git a/docs/architecture/microservices/net-core-net-framework-containers/official-net-docker-images.md b/docs/architecture/microservices/net-core-net-framework-containers/official-net-docker-images.md
index f382f313dd2b9..295755a029ede 100644
--- a/docs/architecture/microservices/net-core-net-framework-containers/official-net-docker-images.md
+++ b/docs/architecture/microservices/net-core-net-framework-containers/official-net-docker-images.md
@@ -1,7 +1,7 @@
---
title: Official .NET Docker images
description: .NET Microservices Architecture for Containerized .NET Applications | Official .NET Docker images
-ms.date: 01/13/2021
+ms.date: 11/19/2021
---
# Official .NET Docker images
@@ -26,13 +26,13 @@ Why multiple images? When developing, building, and running containerized applic
### During development and build
-During development, what is important is how fast you can iterate changes, and the ability to debug the changes. The size of the image isn't as important as the ability to make changes to your code and see the changes quickly. Some tools and "build-agent containers", use the development .NET image (*mcr.microsoft.com/dotnet/sdk:5.0*) during development and build process. When building inside a Docker container, the important aspects are the elements that are needed to compile your app. This includes the compiler and any other .NET dependencies.
+During development, what is important is how fast you can iterate changes, and the ability to debug the changes. The size of the image isn't as important as the ability to make changes to your code and see the changes quickly. Some tools and "build-agent containers", use the development .NET image (*mcr.microsoft.com/dotnet/sdk:6.0*) during development and build process. When building inside a Docker container, the important aspects are the elements that are needed to compile your app. This includes the compiler and any other .NET dependencies.
Why is this type of build image important? You don't deploy this image to production. Instead, it's an image that you use to build the content you place into a production image. This image would be used in your continuous integration (CI) environment or build environment when using Docker multi-stage builds.
### In production
-What is important in production is how fast you can deploy and start your containers based on a production .NET image. Therefore, the runtime-only image based on *mcr.microsoft.com/dotnet/aspnet:5.0* is small so that it can travel quickly across the network from your Docker registry to your Docker hosts. The contents are ready to run, enabling the fastest time from starting the container to processing results. In the Docker model, there is no need for compilation from C\# code, as there is when you run dotnet build or dotnet publish when using the build container.
+What is important in production is how fast you can deploy and start your containers based on a production .NET image. Therefore, the runtime-only image based on *mcr.microsoft.com/dotnet/aspnet:6.0* is small so that it can travel quickly across the network from your Docker registry to your Docker hosts. The contents are ready to run, enabling the fastest time from starting the container to processing results. In the Docker model, there is no need for compilation from C\# code, as there is when you run dotnet build or dotnet publish when using the build container.
In this optimized image, you put only the binaries and other content needed to run the application. For example, the content created by `dotnet publish` contains only the compiled .NET binaries, images, .js, and .css files. Over time, you will see images that contain pre-jitted (the compilation from IL to native that occurs at run time) packages.
@@ -42,8 +42,10 @@ When you explore the .NET image repositories at Docker Hub, you will find multip
| Image | Comments |
|-------|----------|
-| mcr.microsoft.com/dotnet/aspnet:**5.0** | ASP.NET Core, with runtime only and ASP.NET Core optimizations, on Linux and Windows (multi-arch) |
-| mcr.microsoft.com/dotnet/sdk:**5.0** | .NET 5, with SDKs included, on Linux and Windows (multi-arch) |
+| mcr.microsoft.com/dotnet/aspnet:**6.0** | ASP.NET Core, with runtime only and ASP.NET Core optimizations, on Linux and Windows (multi-arch) |
+| mcr.microsoft.com/dotnet/sdk:**6.0** | .NET 6, with SDKs included, on Linux and Windows (multi-arch) |
+
+You can find all the available docker images in [dotnet-docker](https://github.com/dotnet/dotnet-docker) and also refer to the latest preview releases by using nightly build `mcr.microsoft.com/dotnet/nightly/*`
> [!div class="step-by-step"]
> [Previous](net-container-os-targets.md)
diff --git a/docs/architecture/microservices/toc.yml b/docs/architecture/microservices/toc.yml
index 43fe4ce7154e6..e163013f85cbd 100644
--- a/docs/architecture/microservices/toc.yml
+++ b/docs/architecture/microservices/toc.yml
@@ -10,7 +10,7 @@
href: container-docker-introduction/docker-terminology.md
- name: Docker containers, images, and registries
href: container-docker-introduction/docker-containers-images-registries.md
- - name: Choosing Between .NET 5 and .NET Framework for Docker Containers
+ - name: Choosing Between .NET 6 and .NET Framework for Docker Containers
href: net-core-net-framework-containers/index.md
items:
- name: General guidance