Acrolinx (#36528)

docs/azure/sdk/includes/sdk-auth-overview-dev-accounts.md

@@ -1,6 +1,6 @@
-In this method, a developer must be signed-in to Azure from either Visual Studio, the Azure Tools extension for VS Code, the Azure CLI, or Azure PowerShell on their local workstation.  The application then can access the developer's credentials from the credential store and use those credentials to access Azure resources from the app.<br>
+In this method, a developer must be signed in to Azure from either Visual Studio, the Azure Tools extension for VS Code, the Azure CLI, or Azure PowerShell on their local workstation. The application can then access the developer's credentials from the credential store and use those credentials to access Azure resources from the app.<br>
 <br>
-This method has the advantage of easier setup since a developer only needs to login to their Azure account from Visual Studio, VS Code or the Azure CLI.  The disadvantage of this approach is that the developer's account likely has more permissions than required by the application, therefore not properly replicating the permissions the app will run with in production.<br>
+This method has the advantage of easier setup since a developer only needs to log in to their Azure account from Visual Studio, VS Code, or the Azure CLI. The disadvantage of this approach is that the developer's account likely has more permissions than required by the application. Therefore, this approach doesn't accurately replicate the permissions the app will run with in production.<br>
 <br>
 > [!div class="nextstepaction"]
 > [Learn about auth from Azure-hosted apps](../authentication/local-development-dev-accounts.md)

docs/azure/sdk/unit-testing-mocking.md

@@ -27,7 +27,7 @@ To create a test service client, you can either use a mocking library or standar
 
 # [Non-library](#tab/csharp)
 
-To create a test client instance using C# without a mocking library, inherit from the client type and override methods you are calling in your code with an implementation that returns a set of test objects. Most clients contain both synchronous and asynchronous methods for operations; override only the one your application code is calling.
+To create a test client instance using C# without a mocking library, inherit from the client type and override methods you're calling in your code with an implementation that returns a set of test objects. Most clients contain both synchronous and asynchronous methods for operations; override only the one your application code is calling.
 
 > [!NOTE]
 > It can be cumbersome to manually define test classes, especially if you need to customize behavior differently for each test. Consider using a library like Moq or NSubstitute to streamline your testing.
@@ -49,10 +49,10 @@ To create a test client instance using C# without a mocking library, inherit fro
 Model types hold the data being sent and received from Azure services. There are three types of models:
 
 * **Input models** are intended to be created and passed as parameters to service methods by developers. They have one or more public constructors and writeable properties.
-* **Output models** are only returned by the service and have neither public constructors nor writeable properties.
+* **Output models** are only returned by the service and have no public constructors or writeable properties.
 * **Round-trip models** are less common, but are returned by the service, modified, and used as an input.
 
-To create a test instance of an input model use one of the available public constructors and set the additional properties you need.
+To create a test instance of an input model, use one of the available public constructors and set the additional properties you need.
 
 ```csharp
 var secretProperties = new SecretProperties("secret")
@@ -72,7 +72,7 @@ KeyVaultSecret keyVaultSecret = SecretModelFactory.KeyVaultSecret(
 > Some input models have read-only properties that are only populated when the model is returned by the service. In this case, a model factory method will be available that allows setting these properties. For example, <xref:Azure.Security.KeyVault.Secrets.SecretModelFactory.SecretProperties%2A>.
 
 ```csharp
-// CreatedOn is a read-only property and can only be 
+// CreatedOn is a read-only property and can only be
 // set via the model factory's SecretProperties method.
 secretPropertiesWithCreatedOn = SecretModelFactory.SecretProperties(
     name: "secret", createdOn: DateTimeOffset.Now);
@@ -84,7 +84,7 @@ The <xref:Azure.Response> class is an abstract class that represents an HTTP res
 
 ## [Non-library](#tab/csharp)
 
-The `Response` class is abstract, which means there are a lot of members to override. Consider using a library to streamline your approach.
+The `Response` class is abstract, which means there are many members to override. Consider using a library to streamline your approach.
 
 :::code language="csharp" source="snippets/unit-testing/NonLibrary/MockResponse.cs" :::
 
@@ -118,7 +118,7 @@ Some services also support using the <xref:Azure.Response%601> type, which is a
 
 The <xref:Azure.Page%601> class is used as a building block in service methods that invoke operations returning results in multiple pages. The `Page<T>` is rarely returned from APIs directly but is useful to create the `AsyncPageable<T>` and `Pageable<T>` instances in the next section. To create a `Page<T>` instance, use the <xref:Azure.Page%601.FromValues%2A?displayProperty=nameWithType> method, passing a list of items, a continuation token, and the `Response`.
 
-The `continuationToken` parameter is used to retrieve the next page from the service. For unit testing purposes, it should be set to `null` for the last page and should be non-empty for other pages.
+The `continuationToken` parameter is used to retrieve the next page from the service. For unit testing purposes, it should be set to `null` for the last page and should be nonempty for other pages.
 
 ## [Non-library](#tab/csharp)
 
@@ -181,7 +181,7 @@ When unit testing you only want the unit tests to verify the application logic a
 
 ## Refactor your types for testability
 
-Classes that need to be tested should be designed for [dependency injection](/dotnet/azure/sdk/dependency-injection), which allows the class to receive its dependencies instead of creating them internally. It was a seamless process to replace the `SecretClient` implementation in the example from the previous section because it was one of the constructor parameters. However, there may be classes in your code that create their own dependencies and are not easily testable, such as the following:
+Classes that need to be tested should be designed for [dependency injection](/dotnet/azure/sdk/dependency-injection), which allows the class to receive its dependencies instead of creating them internally. It was a seamless process to replace the `SecretClient` implementation in the example from the previous section because it was one of the constructor parameters. However, there may be classes in your code that create their own dependencies and aren't easily testable, such as the following:
 
 ```csharp
 public class AboutToExpireSecretFinder
@@ -201,9 +201,9 @@ The simplest refactoring you can do to enable testing with dependency injection
 ```csharp
 public class AboutToExpireSecretFinder
 {
-    public AboutToExpireSecretFinder(TimeSpan threshold, SecretClient client = null) 
-    { 
-        _threshold = threshold; 
+    public AboutToExpireSecretFinder(TimeSpan threshold, SecretClient client = null)
+    {
+        _threshold = threshold;
         _client = client ?? new SecretClient(
             new Uri(Environment.GetEnvironmentVariable("KeyVaultUri")),
             new DefaultAzureCredential());
@@ -224,7 +224,7 @@ public class AboutToExpireSecretFinder
 }
 
 var secretClient = new SecretClient(
-    new Uri(Environment.GetEnvironmentVariable("KeyVaultUri")), 
+    new Uri(Environment.GetEnvironmentVariable("KeyVaultUri")),
     new DefaultAzureCredential());
 var finder = new AboutToExpireSecretFinder(TimeSpan.FromDays(2), secretClient);
 ```

docs/core/compatibility/aspnet-core/8.0/trimmode-full.md

@@ -17,7 +17,7 @@ Previously, `TrimMode=partial` was set by default for all projects that targeted
 
 ## New behavior
 
-Starting in .NET 8, all the assemblies in the app are trimmed, by default. Apps that previously worked with `PublishTrimmed=true` and `TrimMode=partial` might not work in .NET 8 Preview 7 and later versions. However, only apps with trim warnings are affected. If your app has no trim warnings, the change in behavior should not cause any adverse effects.
+Starting in .NET 8, all the assemblies in the app are trimmed, by default. Apps that previously worked with `PublishTrimmed=true` and `TrimMode=partial` might not work in .NET 8 Preview 7 and later versions. However, only apps with trim warnings are affected. If your app has no trim warnings, the change in behavior shouldn't cause any adverse effects.
 
 ## Type of breaking change
 

docs/core/docker/build-container.md

@@ -155,7 +155,7 @@ Create a file named *Dockerfile* in the directory containing the *.csproj* and o
 > [!TIP]
 > This _Dockerfile_ uses multi-stage builds, which optimizes the final size of the image by layering the build and leaving only required artifacts. For more information, see [Docker Docs: multi-stage builds](https://docs.docker.com/build/building/multi-stage/).
 
-The `FROM` keyword requires a fully qualified Docker container image name. The Microsoft Container Registry (MCR, mcr.microsoft.com) is a syndicate of Docker Hub — which hosts publicly accessible containers. The `dotnet` segment is the container repository, whereas the `sdk` or `aspnet` segment is the container image name. The image is tagged with `7.0`, which is used for versioning. Thus, `mcr.microsoft.com/dotnet/aspnet:7.0` is the .NET 7.0 runtime. Make sure that you pull the runtime version that matches the runtime targeted by your SDK. For example, the app created in the previous section used the .NET 7.0 SDK and the base image referred to in the *Dockerfile* is tagged with **7.0**.
+The `FROM` keyword requires a fully qualified Docker container image name. The Microsoft Container Registry (MCR, mcr.microsoft.com) is a syndicate of Docker Hub—which hosts publicly accessible containers. The `dotnet` segment is the container repository, whereas the `sdk` or `aspnet` segment is the container image name. The image is tagged with `7.0`, which is used for versioning. Thus, `mcr.microsoft.com/dotnet/aspnet:7.0` is the .NET 7.0 runtime. Make sure that you pull the runtime version that matches the runtime targeted by your SDK. For example, the app created in the previous section used the .NET 7.0 SDK and the base image referred to in the *Dockerfile* is tagged with **7.0**.
 
 Save the *Dockerfile* file. The directory structure of the working folder should look like the following. Some of the deeper-level files and folders have been omitted to save space in the article:
 
@@ -259,7 +259,7 @@ Now that you have an image that contains your app, you can create a container. Y
 docker create --name core-counter counter-image
 ```
 
-The `docker create` command from above will create a container based on the **counter-image** image. The output of that command shows you the **CONTAINER ID** (yours will be different) of the created container:
+This `docker create` command will create a container based on the **counter-image** image. The output of that command shows you the **CONTAINER ID** (yours will be different) of the created container:
 
 ```console
 d0be06126f7db6dd1cee369d911262a353c9b7fb4829a0c11b4b2eb7b2d429cf
@@ -355,7 +355,7 @@ Counter: 5
 ^C
 ```
 
-The container also passes parameters into the execution of the .NET app. To instruct the .NET app to count only to 3 pass in 3.
+The container also passes parameters into the execution of the .NET app. To instruct the .NET app to count only to three, pass in 3.
 
 ```console
 docker run -it --rm counter-image 3

docs/core/docker/introduction.md

@@ -1,13 +1,13 @@
 ---
 title: Introduction to Docker
-description: This article provides an introduction and overview to Docker in the context of a .NET Core application.
+description: This article provides an introduction and overview to Docker in the context of a .NET application.
 ms.date: 03/20/2019
 ms.custom: "mvc"
 ---
 
 # Introduction to .NET and Docker
 
-.NET Core can easily run in a Docker container. Containers provide a lightweight way to isolate your application from the rest of the host system, sharing just the kernel, and using resources given to your application. If you're unfamiliar with Docker, it's highly recommended that you read through Docker's [overview documentation](https://docs.docker.com/engine/docker-overview/).
+.NET can easily run in a Docker container. Containers provide a lightweight way to isolate your application from the rest of the host system, sharing just the kernel, and using resources given to your application. If you're unfamiliar with Docker, it's highly recommended that you read through Docker's [overview documentation](https://docs.docker.com/engine/docker-overview/).
 
 For more information about how to install Docker, see the download page for [Docker Desktop: Community Edition](https://www.docker.com/products/docker-desktop).
 
@@ -17,7 +17,7 @@ There are a few concepts you should be familiar with. The Docker client has a CL
 
 ### Images
 
-An image is an ordered collection of filesystem changes that form the basis of a container. The image doesn't have a state and is read-only. Much the time an image is based on another image, but with some customization. For example, when you create a new image for your application, you would base it on an existing image that already contains the .NET Core runtime.
+An image is an ordered collection of filesystem changes that form the basis of a container. The image doesn't have a state and is read-only. An image is commonly based on another image, but with some customization. For example, when you create a new image for your application, you would base it on an existing image that already contains the .NET runtime.
 
 Because containers are created from images, images have a set of run parameters (such as a starting executable) that run when the container starts.
 
@@ -29,17 +29,17 @@ A container is a runnable instance of an image. As you build your image, you dep
 
 Container registries are a collection of image repositories. You can base your images on a registry image. You can create containers directly from an image in a registry. The [relationship between Docker containers, images, and registries](../../architecture/microservices/container-docker-introduction/docker-containers-images-registries.md) is an important concept when [architecting and building containerized applications or microservices](../../architecture/microservices/architect-microservice-container-applications/index.md). This approach greatly shortens the time between development and deployment.
 
-Docker has a public registry hosted at the [Docker Hub](https://hub.docker.com/) that you can use. [.NET Core related images](https://hub.docker.com/_/microsoft-dotnet/) are listed at the Docker Hub.
+Docker has a public registry hosted at the [Docker Hub](https://hub.docker.com/) that you can use. [.NET-related images](https://hub.docker.com/_/microsoft-dotnet/) are listed at the Docker Hub.
 
-The [Microsoft Container Registry (MCR)](/azure/container-registry) is the official source of Microsoft-provided container images. The MCR is built on Azure CDN to provide globally-replicated images. However, the MCR does not have a public-facing website and the primary way to learn about Microsoft-provided container images is through the [Microsoft Docker Hub pages](https://hub.docker.com/_/microsoft-dotnet/).
+The [Microsoft Container Registry (MCR)](/azure/container-registry) is the official source of Microsoft-provided container images. The MCR is built on Azure CDN to provide globally replicated images. However, the MCR doesn't have a public-facing website, and the primary way to learn about Microsoft-provided container images is through the [Microsoft Docker Hub pages](https://hub.docker.com/_/microsoft-dotnet/).
 
 ### Dockerfile
 
-A **Dockerfile** is a file that defines a set of instructions that creates an image. Each instruction in the **Dockerfile** creates a layer in the image. For the most part, when you rebuild the image, only the layers that have changed are rebuilt. The **Dockerfile** can be distributed to others and allows them to recreate a new image in the same manner you created it. While this allows you to distribute the *instructions* on how to create the image, the main way to distribute your image is to publish it to a registry.
+A **Dockerfile** is a file that defines a set of instructions that creates an image. Each instruction in the **Dockerfile** creates a layer in the image. Usually, when you rebuild the image, only the layers that have changed are rebuilt. The **Dockerfile** can be distributed to others and allows them to recreate a new image in the same manner you created it. While this allows you to distribute the *instructions* on how to create the image, the main way to distribute your image is to publish it to a registry.
 
 ## .NET images
 
-Official .NET Docker images are published to the Microsoft Container Registry (MCR) and are discoverable at the [Microsoft .NET Docker Hub repository](https://hub.docker.com/_/microsoft-dotnet/). Each repository contains images for different combinations of the .NET (SDK or Runtime) and OS that you can use.
+Official .NET Docker images are published to the Microsoft Container Registry (MCR) and are discoverable at the [Microsoft .NET Docker Hub repository](https://hub.docker.com/_/microsoft-dotnet/). Each repository contains images for different combinations of the .NET SDK or .NET runtime and operating system that you can use.
 
 Microsoft provides images that are tailored for specific scenarios. For example, the [ASP.NET Core repository](https://hub.docker.com/_/microsoft-dotnet-aspnet/) provides images that are built for running ASP.NET Core apps in production.