Official announcement of .NET 7 Preview 3

We are happy to announce that we have released .NET 7 Preview 3 . The third preview of .NET 7 includes enhancements to observability, startup time, codegen, GC regions, native AOT compilation, and more. You can get it now and start trying new features, including:

• Native AOT
• Default GC regions
• ASP.NET Core startup time improvements

You can download .NET 7 Preview 3 for Windows, macOS, and Linux.

• Installers and Binaries
• picture of container
• Linux package
• release notes
• known issues
• GitHub issue tracker

.NET 7 Preview 3 has been tested in Visual Studio 17.2 Preview 3. If you want to try out the .NET 7 and Visual Studio lineup, we recommend the preview . The Mac version of Visual Studio does not yet support the .NET 7 preview, but it will be released soon. Now, let's take a look at some of the latest updates in this release.

Faster and lighter native AOT applications

In the .NET 7 Preview 2 blog post, we announced that the native AOT project has moved from experimental status to mainline development for .NET 7 in the .NET/runtime repo. We know that many of you are eagerly awaiting an update from the team on Native AOT, and we have some new updates in preview 3.

If you want to know the details of native AOT, or want to get started with it, the repo documentation is the best option.

We also realize that some of you may not be familiar with what native AOT is, so we wanted to share a quick overview of it with you.

▌What is native AOT?

Ahead-of-time compilation (AOT) refers to a family of techniques that generate code at application build time, rather than runtime. AOT is not new to .NET. Today we released ReadyToRun for client and server scenarios, and Mono AOT for mobile and WASM. Native AOT brings full native precompilation to .NET desktop client and server scenarios. Rather than replacing these existing technologies, native AOT provides a new set of capabilities that unlock new form factors.
Existing AOT-compiled .NET assemblies contain platform-specific data structures and native code for preloading work that is usually done at runtime. Precompiling these artifacts saves time at startup (eg ReadyToRun ) and allows access to non-JIT platforms (eg iOS). If precompiling is not possible, .NET either falls back to JIT or to interpretation (depending on the platform).

Native AOT is similar to .NET's existing AOT technology, but it only generates native artifacts. In fact, the native AOT runtime doesn't know how to read the .NET assembly file format - all of which is native to the platform. Executable format parsing is entirely handled by the underlying operating system.

The main advantages of native AOT are in startup time, memory usage, access to restricted platforms (no JIT allowed) and smaller disk size. An application starts running when the operating system places pages from the application into memory. Data structures are optimized for running AOT-generated code, not for compiling new code at runtime. This is similar to how languages like Go, Swift, and Rust compile. Native AOT is best suited for environments where startup time is very important. The requirements for native AOT are stricter than for general .NET Core/5+ applications and libraries. Native AOT prohibits the emission of new code (such as Reflection.Emit ) at runtime, and also the loading of new .NET assemblies (such as plug-in models) at runtime.

▌Prepare applications for native AOT

For .NET 7, we have console apps and native libraries as the main scenarios for native AOT. Application developers and library authors can now take advantage of native AOT by ensuring that their applications are adaptable. Since clipping is a requirement for native AOT compilation, preparing applications and libraries for clipping now will help them prepare for native AOT. If you are the author of any of the .NET libraries, following the " Trim Libraries " instructions will help you prepare for the Trim library and native AOT.

One application we plan to release in .NET 7 using native AOT compilation is the Crossgen tool. Crossgen is part of the .NET SDK. The CoreCLR AOT compiler generates the ReadyToRun executable. Crossgen is written in c#, and we currently publish it as a ReadyToRun app after compilation. We've seen some very promising numbers in terms of compilation speed and size. Crossgen benefits a lot from native AOT because it is a short-lived process and startup overhead dominates the overall execution time:

Going forward, native AOT compatibility will improve in the next few versions of .NET, but there are always reasons to choose JIT in many cases. We will also add more support for publishing projects using native AOT in the dotnet SDK.

observability

.NET 7 continues support for the cloud-native OpenTelemetry specification. Preview 3 added support for spec upgrades #988 and #1708 to make the sampler's tracking state mutable.

• Allow trace sampler to modify active trace state

 //  ActivityListener 采样回调
    listener.Sample = (ref ActivityCreationOptions<ActivityContext> activityOptions) =>
    {
        activityOptions = activityOptions with { TraceState = "rojo=00f067aa0ba902b7" };
        return ActivitySamplingResult.AllDataAndRecorded;
    };

System.Composition.Hosting

The latest managed extensibility framework has been slightly updated to align with previous versions of the API. The new API allows adding a single object instance to the System.Composition.Hosting container . Similar to functionality provided in legacy interface System.ComponentModel.Composition.Hosting and ComposeExportedValue(compostioncontainer, T) ( https://aka.ms/exportedvalue )

Recommendation: Inject existing objects into MEF2

 namespace System.Composition.Hosting
{
      public class ContainerConfiguration{
 public ContainerConfiguration WithExport<TExport>(TExport exportedInstance);
 public ContainerConfiguration WithExport<TExport>(TExport exportedInstance,                             string contractName = null, IDictionary<string, object> metadata = null);
 public ContainerConfiguration WithExport(Type contractType, object exportedInstance);
 public ContainerConfiguration WithExport(Type contractType, object exportedInstance, string contractName = null, IDictionary<string, object> metadata = null);
    }
}

Startup time improved with Write-Xor-Execute enabled

Performance is still the main focus of .NET 7. The dotnet/runtime#65738 PR reimplemented the precoding and call count stubs (staged compilation helper stubs) to significantly reduce the amount of post-creation modification of executable code in the runtime. This improves startup time by 10-15%.

Also, even without Write-Xor-Execute enabled, this change brings steady-state performance gains (up to 8%) in some microbenchmarks and some ASPNet benchmarks.

However, there will also be some regressions caused by this change (Write-Xor-Execute is not enabled) in the upcoming preview release. This is observed in Orchard and fortune benchmark results on Intel processors.

Loop optimization

• For System.Collections.Tests.Perf_BitArray.BitArrayLeftShift (dimensions: 512), loop clone improves the duration of a single call by 21%.

General optimization

• Remove the extra copy of the struct from the called object returned in the hidden buffer
  https://github.com/dotnet/runtime/pull/64130
• Expand String.Equals and str.StartsWith to represent constant strings
  https://github.com/dotnet/runtime/pull/65288
• Extend Equals/StartsWith to auto-vectorize for OrdinalIgnoreCase
  https://github.com/dotnet/runtime/pull/66095
• Movzx optimization after setcc shows 0.03 ~ 0.16% reduction in code size
  https://github.com/dotnet/runtime/pull/66245

GC regions are enabled by default

In Preview 3, the region feature is enabled by default, which helps improve memory utilization for high-throughput applications. The feature is now enabled on all platforms except MacOS and native AOT (which will be enabled in the future). More details can be found in this issue .

Because of how regions are initially allocated, we expect the working set of smaller applications to increase. If you notice any functional or performance differences, please create an issue in the runtime repo.

Cryptography: Better X.500 Name Generation

This change simplifies working with certificates by introducing a class that resolves X.500 names more clearly.

Makes building x500distishedname safer and easier

Generally speaking, anyone who wants to construct an X.500 name (such as creating a test certificate with the CertificateRequest class) does so through string manipulation, either through simple literals or through string formatting, E.g:

 request = new CertificateRequest($"CN={subjectName},OU=Test,O=""Fabrikam, Inc.""", ...);

This is usually no problem unless subjectName contains commas, quotes, or anything else that has an effect on the parser. To fix this, we added the x500 distishednamebuilder class. Because each method operates on only one Relative Distinguished Name (RDN), there is no ambiguity during parsing. Plus, thanks to the expanded RDN identifiers, you no longer have to guess what "CN" stands for
(“Common Name”).

 X500DistinguishedNameBuilder nameBuilder = new();
nameBuilder.AddCommonName(subjectName);
nameBuilder.AddOrganizationalUnitName("Test");
nameBuilder.AddOrganizationName("Fabrikam, Inc.");
​
request = new CertificateRequest(nameBuilder.Build(), ...);

for .NET 7

To target .NET 7, you need to use the .NET 7 Target Framework Codename (TFM) in your project files. E.g:

 <TargetFramework>net7.0</TargetFramework>

See the complete .NET 7 tfm collection, including operation-specific tfm.

• net7.0
• net7.0-android
• net7.0-ios
• net7.0-maccatalyst
• net7.0-macos
• net7.0-tvos
• net7.0-windows

We hope that upgrading from .NET 6 to .NET 7 should be simple. Feel free to tell us about any breaking changes you find while testing your existing applications with .NET 7.

support

.NET 7 is a current release, which means it will receive free support and patches for 18 months from the release date. It is worth noting that the quality of all versions is the same. The only difference is the supported length. For more information on the .NET Support Policy, see Official Support Policy for .NET and .NET Core .

major changes

You can find a list of the latest breaking changes in .NET 7 by reading the Breaking Changes in .NET 7 documentation. It lists breaking changes by region and version, with links to detailed explanations.
To see what breaking changes have been proposed, but are still in the review stage, follow the github issue of breaking.NET changes .

route map

A .NET distribution includes products, libraries, runtimes, and tools, and represents the collaboration of multiple teams within and outside Microsoft. You can learn more about these areas by reading the product roadmap:

• ASP.NET Core 7 and Blazor Roadmap
  https://github.com/dotnet/aspnetcore/issues/39504
• EF 7 Roadmap
  https://docs.microsoft.com/en-us/ef/core/what-is-new/ef-core-7.0/plan?ocid=AID3042760
• ML.NET
  https://github.com/dotnet/machinelearning/blob/main/ROADMAP.md
• .NET MAUI
  https://github.com/dotnet/maui/wiki/Roadmap
• WinForms
  https://github.com/dotnet/winforms/blob/main/docs/roadmap.md
• WPF
  https://github.com/dotnet/wpf/blob/main/roadmap.md
• NuGet
  https://github.com/NuGet/Home/issues/11571
• Roslyn
• Runtime
  https://github.com/dotnet/core/blob/main/roadmap.md

Thank you for all your support and contributions to .NET. Please give .NET 7 Preview 3 a try and let us know what you think!
.NET 7 Preview 3