From 0317ff36382b3134504d3f07b649b08b89b38168 Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 15 Oct 2025 20:22:11 +0000 Subject: [PATCH 1/5] Initial plan From 7fe683ff94bce15fc8ff27aa585f515f8a7c6c2d Mon Sep 17 00:00:00 2001 From: "copilot-swe-agent[bot]" <198982749+Copilot@users.noreply.github.com> Date: Wed, 15 Oct 2025 20:27:52 +0000 Subject: [PATCH 2/5] Update .NET 10 What's New articles for RC 2 Co-authored-by: BillWagner <493969+BillWagner@users.noreply.github.com> --- docs/core/whats-new/dotnet-10/libraries.md | 4 +- docs/core/whats-new/dotnet-10/overview.md | 4 +- docs/core/whats-new/dotnet-10/runtime.md | 4 +- docs/core/whats-new/dotnet-10/sdk.md | 63 +++++++++++++++++++++- 4 files changed, 67 insertions(+), 8 deletions(-) diff --git a/docs/core/whats-new/dotnet-10/libraries.md b/docs/core/whats-new/dotnet-10/libraries.md index 7a9a2425ca3d0..f0e3bf8597835 100644 --- a/docs/core/whats-new/dotnet-10/libraries.md +++ b/docs/core/whats-new/dotnet-10/libraries.md @@ -2,14 +2,14 @@ title: What's new in .NET libraries for .NET 10 description: Learn about the updates to the .NET libraries for .NET 10. titleSuffix: "" -ms.date: 09/09/2025 +ms.date: 10/15/2025 ai-usage: ai-assisted ms.update-cycle: 3650-days --- # What's new in .NET libraries for .NET 10 -This article describes new features in the .NET libraries for .NET 10. It's been updated for RC 1. +This article describes new features in the .NET libraries for .NET 10. It's been updated for RC 2. ## Cryptography diff --git a/docs/core/whats-new/dotnet-10/overview.md b/docs/core/whats-new/dotnet-10/overview.md index f10a0d5596b7c..1ffca77d92077 100644 --- a/docs/core/whats-new/dotnet-10/overview.md +++ b/docs/core/whats-new/dotnet-10/overview.md @@ -2,14 +2,14 @@ title: What's new in .NET 10 description: Learn about the new features introduced in .NET 10 for the runtime, libraries, and SDK. Also find links to what's new in other areas, such as ASP.NET Core. titleSuffix: "" -ms.date: 09/09/2025 +ms.date: 10/15/2025 ai-usage: ai-assisted ms.update-cycle: 3650-days --- # What's new in .NET 10 -Learn about the new features in .NET 10 and find links to further documentation. This page has been updated for RC 1. +Learn about the new features in .NET 10 and find links to further documentation. This page has been updated for RC 2. .NET 10, the successor to [.NET 9](../dotnet-9/overview.md), is [supported for three years](https://dotnet.microsoft.com/platform/support/policy/dotnet-core) as a long-term support (LTS) release. You can [download .NET 10 here](https://get.dot.net/10). diff --git a/docs/core/whats-new/dotnet-10/runtime.md b/docs/core/whats-new/dotnet-10/runtime.md index e447b046a2357..5fd1f337fe0e5 100644 --- a/docs/core/whats-new/dotnet-10/runtime.md +++ b/docs/core/whats-new/dotnet-10/runtime.md @@ -2,13 +2,13 @@ title: What's new in .NET 10 runtime description: Learn about the new features introduced in the .NET 10 runtime. titleSuffix: "" -ms.date: 09/09/2025 +ms.date: 10/15/2025 ai-usage: ai-assisted ms.update-cycle: 3650-days --- # What's new in the .NET 10 runtime -This article describes new features and performance improvements in the .NET runtime for .NET 10. It's been updated for RC 1. +This article describes new features and performance improvements in the .NET runtime for .NET 10. It's been updated for RC 2. ## JIT compiler improvements diff --git a/docs/core/whats-new/dotnet-10/sdk.md b/docs/core/whats-new/dotnet-10/sdk.md index 9e28c2e120bce..b92cdd9b854a0 100644 --- a/docs/core/whats-new/dotnet-10/sdk.md +++ b/docs/core/whats-new/dotnet-10/sdk.md @@ -2,14 +2,14 @@ title: What's new in the SDK and tooling for .NET 10 description: Learn about the new .NET SDK features introduced in .NET 10. titleSuffix: "" -ms.date: 09/09/2025 +ms.date: 10/15/2025 ai-usage: ai-assisted ms.update-cycle: 3650-days --- # What's new in the SDK and tooling for .NET 10 -This article describes new features and enhancements in the .NET SDK for .NET 10. It's been updated for RC 1. +This article describes new features and enhancements in the .NET SDK for .NET 10. It's been updated for RC 2. ## .NET tools enhancements @@ -111,6 +111,65 @@ The output provides a structured, machine-readable description of the command's } ``` +## 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). + +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 has a few important differences, the _most_ important of which 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`. + +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. + +### 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. + +```xml + +``` + +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) +- `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. + +With just a bit more work, the Task can be configured to still run in-process when running via `dotnet`: + +```xml + + +``` + +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. + +### Future work + +This is the first step in a longer journey to make MSBuild more flexible and capable. In future releases, additional capabilities will be added to MSBuild to make it easier to write and use .NET Tasks, including: + +- Automatically discovering and loading .NET Tasks without needing to specify `Runtime` or `TaskFactory` metadata +- Reducing the performance overhead of IPC between the MSBuild Engine and the Tasks when running out-of-process +- Supporting the `Host Object` feature for .NET Tasks running out-of-process + +Task Authors can try this and provide feedback at [dotnet/msbuild](https://github.com/dotnet/msbuild/issues/new). + ## File-based apps enhancements .NET 10 brings significant updates to the file-based apps experience, including publish support and native AOT capabilities. For an introduction to file-based apps, see [File-based apps](../../../csharp/tour-of-csharp/overview.md#file-based-apps) and [Building and running C# programs](../../../csharp/fundamentals/program-structure/index.md#building-and-running-c-programs). From 0b459f62cb53c140699d6db362d7aee267f3e409 Mon Sep 17 00:00:00 2001 From: Bill Wagner Date: Wed, 15 Oct 2025 16:36:11 -0400 Subject: [PATCH 3/5] Apply suggestions from code review Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- docs/core/whats-new/dotnet-10/sdk.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/core/whats-new/dotnet-10/sdk.md b/docs/core/whats-new/dotnet-10/sdk.md index b92cdd9b854a0..20acab49dd654 100644 --- a/docs/core/whats-new/dotnet-10/sdk.md +++ b/docs/core/whats-new/dotnet-10/sdk.md @@ -115,13 +115,13 @@ The output provides a structured, machine-readable description of the command's 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). -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 has a few important differences, the _most_ important of which 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 cannot 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. ### 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, 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. ```xml Date: Thu, 16 Oct 2025 08:20:21 -0400 Subject: [PATCH 4/5] Apply suggestions from code review Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com> Co-authored-by: Meaghan Osagie (Lewis) --- docs/core/whats-new/dotnet-10/sdk.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/core/whats-new/dotnet-10/sdk.md b/docs/core/whats-new/dotnet-10/sdk.md index 20acab49dd654..d279c63c6f575 100644 --- a/docs/core/whats-new/dotnet-10/sdk.md +++ b/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 Date: Thu, 16 Oct 2025 08:21:19 -0400 Subject: [PATCH 5/5] Remove future work section Don't discuss what hasn't happened yet. --- docs/core/whats-new/dotnet-10/sdk.md | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/docs/core/whats-new/dotnet-10/sdk.md b/docs/core/whats-new/dotnet-10/sdk.md index d279c63c6f575..7a05a272f7915 100644 --- a/docs/core/whats-new/dotnet-10/sdk.md +++ b/docs/core/whats-new/dotnet-10/sdk.md @@ -160,16 +160,6 @@ Thanks to the `Condition` feature of MSBuild, you can load a Task differently de 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 - -This is the first step in a longer journey to make MSBuild more flexible and capable. In future releases, additional capabilities will be added to MSBuild to make it easier to write and use .NET Tasks, including: - -- Automatically discovering and loading .NET Tasks without needing to specify `Runtime` or `TaskFactory` metadata -- Reducing the performance overhead of IPC between the MSBuild Engine and the Tasks when running out-of-process -- Supporting the `Host Object` feature for .NET Tasks running out-of-process - -Task Authors can try this and provide feedback at [dotnet/msbuild](https://github.com/dotnet/msbuild/issues/new). - ## File-based apps enhancements .NET 10 brings significant updates to the file-based apps experience, including publish support and native AOT capabilities. For an introduction to file-based apps, see [File-based apps](../../../csharp/tour-of-csharp/overview.md#file-based-apps) and [Building and running C# programs](../../../csharp/fundamentals/program-structure/index.md#building-and-running-c-programs).