Merge pull request #42201 from dotnet/main

Merge main into live

docfx.json

@@ -55,7 +55,8 @@
                     "lock-object.md",
                     "method-group-natural-type-improvements.md",
                     "params-collections.md",
-                    "ref-struct-interfaces.md"
+                    "ref-struct-interfaces.md",
+                    "ref-unsafe-in-iterators-async.md"
                 ],
                 "src": "_csharplang/proposals",
                 "dest": "csharp/language-reference/proposals",

docs/architecture/microservices/architect-microservice-container-applications/docker-application-state-data.md

@@ -29,7 +29,7 @@ From the Docker container:
 
 - **Overlay File System**. This Docker feature implements a copy-on-write task that stores updated information to the root file system of the container. That information is "on top" of the original image on which the container is based. If the container is deleted from the system, those changes are lost. Therefore, while it's possible to save the state of a container within its local storage, designing a system around this would conflict with the premise of container design, which by default is stateless.
 
-However, using Docker Volumes is now the preferred way to handle local data in Docker. If you need more information about storage in containers check on [Docker storage drivers](https://docs.docker.com/storage/storagedriver/select-storage-driver/) and [About storage drivers](https://docs.docker.com/storage/storagedriver/).
+However, using Docker Volumes is now the preferred way to handle local data in Docker. If you need more information about storage in containers check on [Docker storage drivers](https://docs.docker.com/engine/storage/drivers/select-storage-driver/) and [About storage drivers](https://docs.docker.com/engine/storage/drivers/).
 
 The following provides more detail about these options:
 

docs/architecture/microservices/docker-application-development-process/docker-app-development-workflow.md

@@ -1,6 +1,6 @@
 ---
 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.
+description: Learn details of the workflow for developing Docker-based applications. Optimize Dockerfiles and use the simplified workflow available in Visual Studio.
 ms.date: 11/19/2021
 ---
 # Development workflow for Docker apps
@@ -12,9 +12,7 @@ The application development life cycle starts at your computer, as a developer,
 Each container (an instance of a Docker image) includes the following components:
 
 - An operating system selection, for example, a Linux distribution, Windows Nano Server, or Windows Server Core.
-
 - Files added during development, for example, source code and application binaries.
-
 - Configuration information, such as environment settings and dependencies.
 
 ## Workflow for developing Docker container-based applications
@@ -91,9 +89,9 @@ In a similar fashion, Visual Studio can also add a `docker-compose.yml` file for
 
 ### Using an existing official .NET Docker image
 
-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.
+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's 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:8.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:8.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've chosen. For instance, if you want to use ASP.NET Core (Linux or Windows), the image to use is `mcr.microsoft.com/dotnet/aspnet:8.0`. Therefore, you just need to specify what base Docker image you'll use for your container. You do that by adding `FROM mcr.microsoft.com/dotnet/aspnet:8.0` to your Dockerfile. This is 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).
 
@@ -108,7 +106,7 @@ COPY ${source:-obj/Docker/publish} .
 ENTRYPOINT ["dotnet", " MySingleContainerWebApp.dll "]
 ```
 
-In this case, the image is based on version 8.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:8.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).
+In this case, the image is based on version 8.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:8.0`. 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.
 
@@ -128,7 +126,7 @@ You can specify additional configuration settings in the Dockerfile, depending o
 
 ### Using multi-arch image repositories
 
-A single repo can contain platform variants, such as a Linux image and a Windows image. This feature allows vendors like Microsoft (base image creators) to create a single repo to cover multiple platforms (that is Linux and Windows). For example, the [.NET](https://hub.docker.com/_/microsoft-dotnet/) repository available in the Docker Hub registry provides support for Linux and Windows Nano Server by using the same repo name.
+A single repo can contain platform variants, such as a Linux image and a Windows image. This feature allows vendors like Microsoft (base image creators) to create a single repo to cover multiple platforms (that is Linux and Windows).
 
 If you specify a tag, targeting a platform that is explicit like in the following cases:
 

docs/architecture/microservices/multi-container-microservice-net-applications/multi-container-applications-docker-compose.md

@@ -158,11 +158,11 @@ docker-compose -f docker-compose.yml -f docker-compose-test.override.yml down
 
 #### Production deployments
 
-You can also use Compose to deploy to a remote Docker Engine. A typical case is to deploy to a single Docker host instance (like a production VM or server provisioned with [Docker Machine](https://docs.docker.com/machine/overview/)).
+You can also use Compose to deploy to a remote Docker Engine. A typical case is to deploy to a single Docker host instance.
 
-If you are using any other orchestrator (Azure Service Fabric, Kubernetes, etc.), you might need to add setup and metadata configuration settings like those in docker-compose.yml, but in the format required by the other orchestrator.
+If you're using any other orchestrator (for example, Azure Service Fabric or Kubernetes), you might need to add setup and metadata configuration settings like those in docker-compose.yml, but in the format required by the other orchestrator.
 
-In any case, docker-compose is a convenient tool and metadata format for development, testing and production workflows, although the production workflow might vary on the orchestrator you are using.
+In any case, docker-compose is a convenient tool and metadata format for development, testing, and production workflows, although the production workflow might vary on the orchestrator you are using.
 
 ### Using multiple docker-compose files to handle several environments
 
@@ -447,18 +447,16 @@ In the container and microservices model, you are constantly starting containers
 
 The .NET team has been doing important work to make .NET and ASP.NET Core a container-optimized framework. Not only is .NET a lightweight framework with a small memory footprint; the team has focused on optimized Docker images for three main scenarios and published them in the Docker Hub registry at *dotnet/*, beginning with version 2.1:
 
-1. **Development**: The priority is the ability to quickly iterate and debug changes, and where size is secondary.
+- **Development**: The priority is the ability to quickly iterate and debug changes, and where size is secondary.
+- **Build**: The priority is compiling the application, and the image includes binaries and other dependencies to optimize binaries.
+- **Production**: The focus is fast deploying and starting of containers, so these images are limited to the binaries and content needed to run the application.
 
-2. **Build**: The priority is compiling the application, and the image includes binaries and other dependencies to optimize binaries.
+The .NET team provides four basic variants in [dotnet/](../net-core-net-framework-containers/official-net-docker-images.md):
 
-3. **Production**: The focus is fast deploying and starting of containers, so these images are limited to the binaries and content needed to run the application.
-
-The .NET team provides four basic variants in [dotnet/](https://hub.docker.com/_/microsoft-dotnet/) (at Docker Hub):
-
-1. **sdk**: for development and build scenarios
-1. **aspnet**: for ASP.NET production scenarios
-1. **runtime**: for .NET production scenarios
-1. **runtime-deps**: for production scenarios of [self-contained applications](../../../core/deploying/index.md#publish-self-contained)
+- **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)
 
 For faster startup, runtime images also automatically set aspnetcore\_urls to port 80 and use Ngen to create a native image cache of assemblies.