Acrolinx 4/24

docs/architecture/containerized-lifecycle/Microsoft-platform-tools-containerized-apps/index.md

@@ -10,7 +10,7 @@ ms.date: 02/15/2019
 Figure 3-1 shows the main pillars in the life cycle of Docker apps classified by the type of work delivered by multiple teams (app-development, DevOps infrastructure processes, and IT management and operations). Usually, in the enterprise, the profiles of "the persona" responsible for each area are different. So are their skills.
 
 :::image type="complex" source="./media/index/microsoft-tools-contanerized-docker-app.png" alt-text="Diagram showing the Microsoft tools needed to maintain Docker apps.":::
-Microsoft tools. For the Develop/Design workload: Docker engine for Windows, VS and VS Code, .NET Core, Azure Kubernetes Service. For the Build/Test/Ship workload: Azure DevOps, Team Foundation Server, Docker CLI, Azure Kubernetes Service. For the Run/Monitor/Manage workload: Azure Monitor, Azure Portal Azure Kubernetes Services, Service Fabric, other orchestrators.
+Microsoft tools. For the Develop/Design workload: Docker engine for Windows, Visual Studio and Visual Studio Code, .NET Core, Azure Kubernetes Service. For the Build/Test/Ship workload: Azure DevOps, Team Foundation Server, Docker CLI, Azure Kubernetes Service. For the Run/Monitor/Manage workload: Azure Monitor, Azure portal, Azure Kubernetes Services, Service Fabric, other orchestrators.
 :::image-end:::
 
 **Figure 3-1.** Main pillars in the life cycle for containerized Docker applications with Microsoft platform and tools

docs/architecture/serverless/serverless-business-scenarios.md

@@ -87,13 +87,13 @@ This sample is a generic function (`.csx` file) that can be used to convert any
 
 ## Serverless for mobile
 
-Azure Functions are easy to implement and maintain, and accessible through HTTP. They are a great way to implement an API for a mobile application. Microsoft offers great cross-platform tools for iOS, Android, and Windows with Xamarin. As such, Xamarin and Azure Functions are working great together. This article shows how to implement an Azure Function in the Azure Web Portal or in Visual Studio at first, and build a cross-platform client with Xamarin.Forms, running on Android, iOS, and Windows.
+Azure Functions are easy to implement and maintain, and accessible through HTTP. They are a great way to implement an API for a mobile application. Microsoft offers great cross-platform tools for iOS, Android, and Windows with Xamarin. As such, Xamarin and Azure Functions are working great together. This article shows how to implement an Azure Function in the Azure portal or in Visual Studio at first, and build a cross-platform client with Xamarin.Forms running on Android, iOS, and Windows.
 
 [Implementing a simple Azure Function with a Xamarin.Forms client](https://docs.microsoft.com/samples/azure-samples/functions-xamarin-getting-started/implementing-a-simple-azure-function-with-a-xamarinforms-client/)
 
 ## Serverless messaging
 
-This sample shows how to utilize Durable Functions' fan out pattern to load an arbitrary number of messages across any number of sessions/partitions. It targets Service Bus, Event Hubs, or Storage Queues. The sample also adds the ability to consume those messages with another Azure Function and load the resulting timing data in to another Event Hub. The data is then ingested into analytics services like Azure Data Explorer.
+This sample shows how to utilize Durable Functions' fan-out pattern to load an arbitrary number of messages across any number of sessions/partitions. It targets Service Bus, Event Hubs, or Storage Queues. The sample also adds the ability to consume those messages with another Azure Function and load the resulting timing data in to another Event Hub. The data is then ingested into analytics services like Azure Data Explorer.
 
 [Produce and Consume messages through Service Bus, Event Hubs, and Storage Queues with Azure Functions](https://docs.microsoft.com/samples/azure-samples/durable-functions-producer-consumer/product-consume-messages-az-functions/)
 

docs/core/compatibility/2.2-3.0.md

@@ -267,7 +267,7 @@ If you're migrating from version 2.2 to version 3.0 of .NET Core, ASP.NET Core,
 - [Floating point formatting and parsing behavior changes](#floating-point-formatting-and-parsing-behavior-changed)
 - [Floating-point parsing operations no longer fail or throw an OverflowException](#floating-point-parsing-operations-no-longer-fail-or-throw-an-overflowexception)
 - [InvalidAsynchronousStateException moved to another assembly](#invalidasynchronousstateexception-moved-to-another-assembly)
-- [NET Core 3.0 follows Unicode best practices when replacing ill-formed UTF-8 byte sequences](#net-core-30-follows-unicode-best-practices-when-replacing-ill-formed-utf-8-byte-sequences)
+- [Replacing ill-formed UTF-8 byte sequences follows Unicode guidelines](#replacing-ill-formed-utf-8-byte-sequences-follows-unicode-guidelines)
 - [TypeDescriptionProviderAttribute moved to another assembly](#typedescriptionproviderattribute-moved-to-another-assembly)
 - [JSON serializer exception type changed from JsonException to NotSupportedException](#json-serializer-exception-type-changed-from-jsonexception-to-notsupportedexception)
 - [Change in semantics of (string)null in Utf8JsonWriter](#change-in-semantics-of-stringnull-in-utf8jsonwriter)

docs/core/compatibility/2.2-3.1.md

@@ -270,7 +270,7 @@ If you're migrating from version 2.2 to version 3.1 of .NET Core, ASP.NET Core,
 - [Floating point formatting and parsing behavior changes](#floating-point-formatting-and-parsing-behavior-changed)
 - [Floating-point parsing operations no longer fail or throw an OverflowException](#floating-point-parsing-operations-no-longer-fail-or-throw-an-overflowexception)
 - [InvalidAsynchronousStateException moved to another assembly](#invalidasynchronousstateexception-moved-to-another-assembly)
-- [NET Core 3.0 follows Unicode best practices when replacing ill-formed UTF-8 byte sequences](#net-core-30-follows-unicode-best-practices-when-replacing-ill-formed-utf-8-byte-sequences)
+- [Replacing ill-formed UTF-8 byte sequences follows Unicode guidelines](#replacing-ill-formed-utf-8-byte-sequences-follows-unicode-guidelines)
 - [TypeDescriptionProviderAttribute moved to another assembly](#typedescriptionproviderattribute-moved-to-another-assembly)
 - [JSON serializer exception type changed from JsonException to NotSupportedException](#json-serializer-exception-type-changed-from-jsonexception-to-notsupportedexception)
 - [Change in semantics of (string)null in Utf8JsonWriter](#change-in-semantics-of-stringnull-in-utf8jsonwriter)

docs/core/compatibility/corefx.md

@@ -16,7 +16,7 @@ The following breaking changes are documented on this page:
 | [Floating point formatting and parsing behavior changes](#floating-point-formatting-and-parsing-behavior-changed) | 3.0 |
 | [Floating-point parsing operations no longer fail or throw an OverflowException](#floating-point-parsing-operations-no-longer-fail-or-throw-an-overflowexception) | 3.0 |
 | [InvalidAsynchronousStateException moved to another assembly](#invalidasynchronousstateexception-moved-to-another-assembly) | 3.0 |
-| [NET Core 3.0 follows Unicode best practices when replacing ill-formed UTF-8 byte sequences](#net-core-30-follows-unicode-best-practices-when-replacing-ill-formed-utf-8-byte-sequences) | 3.0 |
+| [Replacing ill-formed UTF-8 byte sequences follows Unicode guidelines](#replacing-ill-formed-utf-8-byte-sequences-follows-unicode-guidelines) | 3.0 |
 | [TypeDescriptionProviderAttribute moved to another assembly](#typedescriptionproviderattribute-moved-to-another-assembly) | 3.0 |
 | [ZipArchiveEntry no longer handles archives with inconsistent entry sizes](#ziparchiveentry-no-longer-handles-archives-with-inconsistent-entry-sizes) | 3.0 |
 | [JSON serializer exception type changed from JsonException to NotSupportedException](#json-serializer-exception-type-changed-from-jsonexception-to-notsupportedexception) | 3.0 |

docs/core/porting/index.md

@@ -27,7 +27,7 @@ The following tools will be used throughout the process:
 
 ## Porting a solution
 
-When there are multiple projects in a solution the porting can seem more complicated because you must address projects in a specific order. The conversion process should be a bottom-up approach, where the projects with no dependencies on other projects in the solution are converted first, and continue up through the whole solution.
+When there are multiple projects in a solution, the porting can seem more complicated because you must address projects in a specific order. The conversion process should be a bottom-up approach, where the projects with no dependencies on other projects in the solution are converted first, and continue up through the whole solution.
 
 In order to identify the order projects should be migrated, you can use the following tools:
 
@@ -40,7 +40,7 @@ We recommend you use the following process when porting your project to .NET Cor
 
 1. Convert all of your `packages.config` dependencies to the [PackageReference](/nuget/consume-packages/package-references-in-project-files) format with the [conversion tool in Visual Studio](/nuget/consume-packages/migrate-packages-config-to-package-reference).
 
-   This step involves converting your dependencies from the legacy `packages.config` format. `packages.config` doesn't work on .NET Core, so this conversion is required if you have package dependencies. It also only requires the dependencies you are directly using in a project which will make later steps easier by reducing the amount of dependencies you must manage.
+   This step involves converting your dependencies from the legacy `packages.config` format. `packages.config` doesn't work on .NET Core, so this conversion is required if you have package dependencies. It also only requires the dependencies you are directly using in a project, which makes later steps easier by reducing the number of dependencies you must manage.
 
 1. Convert your project file to the new SDK-style files structure. You can create new projects for .NET Core and copy over source files, or attempt to convert your existing project file with a tool.
 
@@ -60,7 +60,7 @@ We recommend you use the following process when porting your project to .NET Cor
 
    While reading the reports generated by the analyzer, the important information is the actual APIs that are being used and not necessarily the percentage of support for the target platform. Many APIs have equivalent options in .NET Standard/Core, and so understanding the scenarios your library or application needs the API for will help determine the implication for portability.
 
-   There are some cases where APIs are not equivalent and you'll need to do some compiler preprocessor directives (i.e. `#if NET45`) to special case the platforms. At this point, you're project will still be targeting .NET Framework. For each of these targeted cases, it is recommended to use well-known conditionals that can be understood as a scenario.  For example, AppDomain support in .NET Core is limited, but for the scenario of loading and unloading assemblies, there is a new API that is not available in .NET Core. A common way to handle this in code would be something like this:
+   There are some cases where APIs are not equivalent and you'll need to do some compiler preprocessor directives (that is, `#if NET45`) to special case the platforms. At this point, your project will still be targeting .NET Framework. For each of these targeted cases, it is recommended to use well-known conditionals that can be understood as a scenario.  For example, AppDomain support in .NET Core is limited, but for the scenario of loading and unloading assemblies, there is a new API that's not available in .NET Core. A common way to handle this in code would be something like this:
 
    ```csharp
    #if FEATURE_APPDOMAIN_LOADING
@@ -78,7 +78,7 @@ We recommend you use the following process when porting your project to .NET Cor
 
 1. At this point, you can switch to targeting .NET Core (generally for applications) or .NET Standard (for libraries).
 
-   The choice between .NET Core and .NET Standard is largely dependent on where the project will be run. If it is a library that will be consumed by other applications or distributed via NuGet, the preference is usually to target .NET Standard. However, there may be APIs that are only available on .NET Core for performance or other reasons; if that's the case, .NET Core should be targeted with potentially a .NET Standard build available as well with reduced performance or funcitonality. By targeting .NET Standard, the project will be ready to run on new platforms (such as WebAssembly). If the project has dependencies on specific app frameworks (such as ASP.NET Core), then the target will be limited by what the dependencies support.
+   The choice between .NET Core and .NET Standard is largely dependent on where the project will be run. If it is a library that will be consumed by other applications or distributed via NuGet, the preference is usually to target .NET Standard. However, there may be APIs that are only available on .NET Core for performance or other reasons; if that's the case, .NET Core should be targeted with potentially a .NET Standard build available as well with reduced performance or functionality. By targeting .NET Standard, the project will be ready to run on new platforms (such as WebAssembly). If the project has dependencies on specific app frameworks (such as ASP.NET Core), then the target will be limited by what the dependencies support.
 
    If there are no preprocessor directives to conditional compile code for .NET Framework or .NET Standard, this will be as simple as finding the following in the project file:
 
@@ -92,17 +92,17 @@ We recommend you use the following process when porting your project to .NET Cor
    <TargetFramework>netcoreapp3.1</TargetFramework>
    ```
 
-   However, if this is a library that you want to continue supporting .NET Framework specific builds for some reason, you can [multi-target](../../standard/library-guidance/cross-platform-targeting.md) by replacing it with the following:
+   However, if this is a library for which you want to continue supporting .NET Framework-specific builds, you can [multi-target](../../standard/library-guidance/cross-platform-targeting.md) by replacing it with the following:
 
    ```xml
    <TargetFrameworks>net472;netstandard2.0</TargetFrameworks>
    ```
 
-   If you're using Windows-specific APIs (such as registry access), you should install the [Windows Compatibility Pack](./windows-compat-pack.md).
+   If you're using Windows-specific APIs (such as registry access), install the [Windows Compatibility Pack](./windows-compat-pack.md).
 
 ## Next steps
 
->[!div class="nextstepaction"]
->[Analyze dependencies](third-party-deps.md)
->[Package NuGet Package](../deploying/creating-nuget-packages.md)
->[ASP.NET to ASP.NET Core Migration](/aspnet/core/migration/proper-to-2x)
+> [!div class="nextstepaction"]
+> [Analyze dependencies](third-party-deps.md)
+> [Package NuGet Package](../deploying/creating-nuget-packages.md)
+> [ASP.NET to ASP.NET Core Migration](/aspnet/core/migration/proper-to-2x)

docs/csharp/misc/cs0200.md

@@ -7,12 +7,14 @@ helpviewer_keywords:
   - "CS0200"
 ms.assetid: 1990704a-edfa-4dbd-8477-d9c7aae58c96
 ---
-# Compiler Error CS0200
+# Compiler error CS0200
+
 Property or indexer 'property' cannot be assigned to -- it is read only
 
-An attempt was made to assign a value to a [property](../programming-guide/classes-and-structs/using-properties.md), but the property does not have a set accessor or the assignment was outside of the constructor. Resolve the error by adding a set accessor. For more information, see [How to declare and use read write properties](../programming-guide/classes-and-structs/how-to-declare-and-use-read-write-properties.md).
+An attempt was made to assign a value to a [property](../programming-guide/classes-and-structs/using-properties.md), but the property does not have a set accessor or the assignment was outside of the constructor. Resolve the error by adding a set accessor. For more information, see [How to declare and use read-write properties](../programming-guide/classes-and-structs/how-to-declare-and-use-read-write-properties.md).
 
 ## Examples
+
 The following sample generates CS0200:
 
 ```csharp
@@ -43,7 +45,7 @@ public class Example
 }  
 ```
 
-The following sample uses [auto-implemented properties](../programming-guide/classes-and-structs/auto-implemented-properties.md), [object initializers](../programming-guide/classes-and-structs/object-and-collection-initializers.md), and still generates CS0200:
+The following sample uses [auto-implemented properties](../programming-guide/classes-and-structs/auto-implemented-properties.md) and [object initializers](../programming-guide/classes-and-structs/object-and-collection-initializers.md) and still generates CS0200:
 
 ```csharp
 // CS0200.cs
@@ -66,7 +68,7 @@ public class Example
 }
 ```
 
-Assignment to a property or indexer 'property' that is read only, can be achieved through adding a set accessor or by assigning to the property in the object's constructor.
+To assign to a property or indexer 'property' that's read-only, add a set accessor or assign the value in the object's constructor.
 
 ```csharp
 public class Example