Apply suggestions from code review

Co-authored-by: Genevieve Warren <[email protected]>
Co-authored-by: Meaghan Osagie (Lewis) <[email protected]>

Author: 3 people

docs/core/whats-new/dotnet-10/sdk.md

@@ -111,17 +111,17 @@ The output provides a structured, machine-readable description of the command's
 }
 ```
 
-## Use .NET MSBuild Tasks with .NET Framework MSBuild
+## Use .NET MSBuild tasks with .NET Framework MSBuild
 
-MSBuild is the underlying build system for .NET, driving both build of projects (as seen in commands like `dotnet build` and `dotnet pack`), as well as acting as a general provider of information about projects (as seen in commands like `dotnet list package`, and implicitly used by commands like `dotnet run` to discover how a project wants to be executed).
+MSBuild is the underlying build system for .NET, driving both build of projects (as seen in commands like `dotnet build` and `dotnet pack`), and acting as a general provider of information about projects (as seen in commands like `dotnet list package`, and implicitly used by commands like `dotnet run` to discover how a project wants to be executed).
 
-When running `dotnet` CLI commands, the version of MSBuild that is used is the one that is shipped with the .NET SDK. However, when using Visual Studio or invoking MSBuild directly, the version of MSBuild that is used is the one that is installed with Visual Studio. This environment difference has a few important consequences. The most important is that MSBuild running in Visual Studio (or through `msbuild.exe`) is a .NET Framework application, while MSBuild running in the `dotnet` CLI is a .NET application. This means that any MSBuild tasks that are written to run on .NET cannot be used when building in Visual Studio or when using `msbuild.exe`.
+When running `dotnet` CLI commands, the version of MSBuild that is used is the one that is shipped with the .NET SDK. However, when using Visual Studio or invoking MSBuild directly, the version of MSBuild that is used is the one that is installed with Visual Studio. This environment difference has a few important consequences. The most important is that MSBuild running in Visual Studio (or through `msbuild.exe`) is a .NET Framework application, while MSBuild running in the `dotnet` CLI is a .NET application. This means that any MSBuild tasks that are written to run on .NET can't be used when building in Visual Studio or when using `msbuild.exe`.
 
-Starting with .NET 10, `msbuild.exe` and Visual Studio 2026 can run MSBuild tasks that are built for .NET. This means that you can now use the same MSBuild tasks when building in Visual Studio or using `msbuild.exe` as you do when building with the `dotnet` CLI. For most .NET users, this won't change anything, but for authors of custom MSBuild tasks, this means that you can now write your tasks to target .NET and have them work everywhere. The goal with this change is to make it easier to write and share MSBuild tasks, and to allow task authors to take advantage of the latest features in .NET—in addition to reducing the difficulties around multi-targeting tasks to support both .NET Framework and .NET, and dealing with versions of .NET Framework dependencies that are implicitly available in the MSBuild .NET Framework execution space.
+Starting with .NET 10, `msbuild.exe` and Visual Studio 2026 can run MSBuild tasks that are built for .NET. This means that you can now use the same MSBuild tasks when building in Visual Studio or using `msbuild.exe` as you do when building with the `dotnet` CLI. For most .NET users, this won't change anything. But for authors of custom MSBuild tasks, this means that you can now write your tasks to target .NET and have them work everywhere. The goal with this change is to make it easier to write and share MSBuild tasks, and to allow task authors to take advantage of the latest features in .NET. In addition, this change reduces the difficulties around multi-targeting tasks to support both .NET Framework and .NET, and dealing with versions of .NET Framework dependencies that are implicitly available in the MSBuild .NET Framework execution space.
 
-### Configure .NET Tasks
+### Configure .NET tasks
 
-For task authors, opting in to this new behavior should be pretty simple—all it should take is changing your `UsingTask` declaration to tell MSBuild about your task.
+For task authors, it's easy to opt into this new behavior. Just change your `UsingTask` declaration to tell MSBuild about your task.
 
 ```xml
 <UsingTask TaskName="MyTask"
@@ -133,14 +133,14 @@ For task authors, opting in to this new behavior should be pretty simple—all i
 
 The `Runtime="NET"` and `TaskFactory="TaskHostFactory"` attributes tell the MSBuild engine how to run the Task:
 
-- `Runtime="NET"` tells MSBuild that the Task is built for .NET (as opposed to .NET Framework)
+- `Runtime="NET"` tells MSBuild that the Task is built for .NET (as opposed to .NET Framework).
 - `TaskFactory="TaskHostFactory"` tells MSBuild to use the `TaskHostFactory` to run the Task, which is an existing capability of MSBuild that allows tasks to be run out-of-process.
 
 ### Caveats and performance tuning
 
-The preceding example is the simplest way to get started using .NET Tasks in MSBuild, but it has some limitations—because the `TaskHostFactory` always runs tasks out-of-process, the new .NET Task always runs in a separate process from MSBuild. This means that there is some minor overhead to running the Task because the MSBuild engine and the Task communicate over inter-process communication (IPC) instead of in-process communication. For most tasks, this overhead is negligible, but for tasks that are run many times in a build, or that do quite a lot of logging, this overhead might be more significant.
+The preceding example is the simplest way to get started using .NET tasks in MSBuild, but it has some limitations. Because the `TaskHostFactory` always runs tasks out-of-process, the new .NET task always runs in a separate process from MSBuild. This means that there is some minor overhead to running the task because the MSBuild engine and the task communicate over inter-process communication (IPC) instead of in-process communication. For most tasks, this overhead is negligible, but for tasks that are run many times in a build, or that do a lot of logging, this overhead might be more significant.
 
-With just a bit more work, the Task can be configured to still run in-process when running via `dotnet`:
+With just a bit more work, you can configure the task to still run in-process when running via `dotnet`:
 
 ```xml
 <UsingTask TaskName="MyTask"
@@ -158,7 +158,7 @@ With just a bit more work, the Task can be configured to still run in-process wh
 
 Thanks to the `Condition` feature of MSBuild, you can load a Task differently depending on whether MSBuild is running in .NET Framework (Visual Studio or `msbuild.exe`) or .NET (the `dotnet` CLI). In this example, the Task runs out-of-process when running in Visual Studio or `msbuild.exe`, but runs in-process when running in the `dotnet` CLI. This gives the best performance when running in the `dotnet` CLI, while still allowing the Task to be used in Visual Studio and `msbuild.exe`.
 
-There are also small technical limitations to be aware of when using .NET Tasks in MSBuild—the most notable of which is that the `Host Object` feature of MSBuild Tasks is not yet supported for .NET Tasks running out-of-process. This means that if your Task relies on a Host Object, it won't work when running in Visual Studio or `msbuild.exe`. Additional support for Host Objects is planned in future releases.
+There are also small technical limitations to be aware of when using .NET Tasks in MSBuild—the most notable of which is that the `Host Object` feature of MSBuild Tasks isn't yet supported for .NET Tasks running out-of-process. This means that if your Task relies on a Host Object, it won't work when running in Visual Studio or `msbuild.exe`. Additional support for Host Objects is planned in future releases.
 
 ### Future work