What's new in .NET 8 Preview 5 [WIP]

[leecow]

What's new in .NET 8 Preview 5

This issue is for teams to highlight work for the community that will release in .NET 8 Preview 5

To add content, use a new conversation entry. The entry should include the team name and feature title as the first line shown in the template below.

Required

## Team Name: Feature title

[link to the tracking issue or epic item for the work]

Tell the story of the feature and anything the community should pay particular attention 
to be successful in using the feature.

Optional

Below are three additional items to consider. These will help the .NET 8 blog team and the community throughout the release.

• Link to documentation.
  • Where can we send people to learn more about the feature?
• Link to where you'd like people to provide feedback for this feature.
  • Where can people best comment on the direction of this feature?
• Whether you would like assistance from the .NET 8 writers to craft a story for this feature.
  • Please @JonDouglas or @JeremyLikness in your comment if so.

Index of .NET 8 releases

Preview 1: #8133
Preview 2: #8134
Preview 3: #8135
Preview 4: #8234
Preview 5: #8436
Preview 6: #8437
Preview 7: #8438
RC 1: #8439
RC 2: #8440

[WeihanLi]

@leecow the preview 6 link is incorrect, should be #8437
The same problem exists in preview 6/7 and rc1/2 issues

[mairaw]

Good catch @WeihanLi. I've fixed those.

[JonDouglas]

.NET Framework -> .NET 7 -> .NET 8 Benchmarks

Method	Runtime	Mean	Error	StdDev
BuildConsole	.NET 7.0	766.1 us	9.20 us	8.61 us
BuildRegex	.NET 7.0	185,561.0 us	3,341.04 us	5,000.71 us
BuildCompiler	.NET 7.0	964,543.7 us	19,287.08 us	27,037.80 us
BuildConsole	.NET 8.0	761.5 us	14.77 us	16.42 us
BuildRegex	.NET 8.0	176,244.4 us	2,601.66 us	4,417.81 us
BuildCompiler	.NET 8.0	944,589.2 us	18,860.02 us	51,629.00 us
BuildConsole	.NET Framework 4.8.1	1,094.1 us	10.63 us	8.88 us
BuildRegex	.NET Framework 4.8.1	410,393.0 us	7,304.48 us	6,099.57 us
BuildCompiler	.NET Framework 4.8.1	2,044,387.2 us	40,654.16 us	48,395.89 us

// * Warnings *
MultimodalDistribution
CompilationBenchmak.BuildCompiler: Runtime=.NET 8.0, Server=True -> It seems that the distribution is bimodal (mValue = 3.44)

Simplified

μs	.NET Framework 4.8.1	.NET 7.0	.NET 8.0
Build Hello World	1,094.10	766.1 (-30.0%)	761.5 (-30.4%)
Build simple app	410,393.00	185,561.0 (-54.8%)	176,244.4 (-57.1%)
Build Roslyn	2,044,387.20	964,543.7 (-52.8%)	944,589.2 (-53.8%)

Source: https://gist.github.com/jaredpar/f2fd4c87917ed0de73981a5ea410015e

[tarekgh]

Enhancements to Metrics APIs

Introducing supplementary metrics APIs to cater to new use cases:

DI Friendly metrics APIs

Introducing the IMeterFactory interface that can be registered in DI containers and utilized to create Meter objects in an isolated manner.

            // services is the DI IServiceCollection 
            // Register the IMeterFactory to the DI container using the default meter factory implementation. 
            services.AddMetrics();

Consumers now have the ability to obtain the meter factory and utilize it for creating a new Meter object.

            IMeterFactory meterFactory = serviceProvider.GetRequiredService<IMeterFactory>();

            MeterOptions options = new MeterOptions("MeterName")
            {
                 Version = "version",
            };

            Meter meter = meterFactory.Create(options);

Enabling the creation of Meters and Instruments with Tags

Introducing the capability to attach key-value pair tags to Meters and Instruments during their creation. This feature allows aggregators of published metric measurements to utilize the tags to differentiate the aggregated values based on these tags.

            MeterOptions options = new MeterOptions("name")
            {
                Version = "version",
                
                // Attach these tags to the created meter
                Tags = new TagList() { { "MeterKey1", "MeterValue1" }, { "MeterKey2", "MeterValue2" } }
            };

            Meter meter = meterFactory.Create(options);
            
            Instrument instrument = meter.CreateCounter<int>("counter", null, null, new TagList() { { "counterKey1", "counterValue1" } });
            instrument. Add(1);

References

dotnet/runtime#77514 (comment)
dotnet/runtime#84321
dotnet/runtime#86740

Please note that the newly exposed APIs are currently undergoing refinements, which may lead to minor changes in their current exposed form.

[baronfel]

SDK: SourceLink is part of the .NET SDK!

The PR is dotnet/sdk#31632

The .NET SDK now includes SourceLink to help power-up the IDE experience when inspecting Sourcelinked NuGet Packages. The goal is that by bundling SourceLink into the SDK, instead of requiring a separate PackageReference for the package, more packages will include this information by default, resulting in better IDE experiences for developers all-up.

Source Link is a language- and source-control agnostic system for providing first-class source debugging experiences for binaries. The goal of the project is to enable anyone building NuGet libraries to provide source debugging for their users with almost no effort. Microsoft libraries, such as .NET Core and Roslyn have enabled Source Link. Source Link is supported by Microsoft.

Visual Studio, and many other editors, support reading Source Link information from symbols while debugging. Editors can download and display the appropriate commit-specific source for users, such as from raw.githubusercontent, enabling breakpoints and all other sources debugging experience on arbitrary NuGet dependencies.

The shipped implementation of SourceLink includes providers for git, GitHub, GitLab, Azure Repositories, and BitBucket, but there are a other providers available on NuGet. You can find more information about SourceLink at the Learn docs, and read more about the available settings the repo documentation.

[AndyAyersMS]

Codegen

@JonDouglas @JeremyLikness feel free to craft away....

Dynamic PGO is now enabled by default. Special configuration settings are no longer needed. We anticipate performance for a broad class of applications will improve by anywhere from 5% to 500% (with 15% a reasonable expectation), depending upon the nature of application bottlenecks. In our local benchmark suite of approximately 4600 tests, 23% improved by 20% or more.

Customer experience with PGO in past releases has been uniformly positive.

• Akka.Net
• Azure Active Directory Gateway
• Microsoft Graph

If you are new to Dynamic PGO we look forward to hearing about your experiences as well (good or bad).

If necessary, you can opt out of Dynamic PGO via

<TieredPGO>false</TieredPGO>

in your .csproj or via similar settings in the runtime config or environment.

[ashnaga]

Linux distribution-built (source-build) SDK now has the capability to build self-contained applications utilizing the source-build runtime packages. Distribution specific runtime package will be bundled with the source-build SDK. During self-contained deployment, this bundled runtime package will be referenced and thereby enabling the feature for the user. Please note that there are no changes for the MS-built SDK. 

Thanks to our Red Hat partners, especially @tmds, for the valuable contribution to enable this feature.  

[baronfel]

SDK: Runtime-specific apps no longer self-contained by default

Since .NET 6, specifying a runtime during publish has resulted in the following warning:

warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used.

For .NET 8, we're finally taking the step of making this change. Going forward, for apps targeting net8.0 and higher Target Frameworks, -r/--runtime will no longer imply --self-contained. If you intended that behavior you'll either need to

• add the CLI option explicitly, or
• add the <SelfContained>true</SelfContained> property to your project files

Apps targeting net7.0 or lower remain unaffected. You can read more about this change in the breaking change notice we've posted.

We're making this change because we believe that targeting a specific platforms is an independent decision from bundling the runtime for that platform. Defaulting more apps to framework-dependent deployments means that the runtime the app runs on can be safely updated without requiring a rebuild or redeployment. It also results in smaller app sizes than self-contained deployments.