search

dotnet / core

.NET news, announcements, release notes, and more!
https://dot.net
MIT License
20.98k stars 4.91k forks source link

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

Closed leecow closed 1 year ago

leecow commented 1 year ago

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.

Index of .NET 8 releases

Preview 1: https://github.com/dotnet/core/issues/8133 Preview 2: https://github.com/dotnet/core/issues/8134 Preview 3: https://github.com/dotnet/core/issues/8135 Preview 4: https://github.com/dotnet/core/issues/8234 Preview 5: https://github.com/dotnet/core/issues/8436 Preview 6: https://github.com/dotnet/core/issues/8437 Preview 7: https://github.com/dotnet/core/issues/8438 RC 1: https://github.com/dotnet/core/issues/8439 RC 2: https://github.com/dotnet/core/issues/8440

WeihanLi commented 1 year ago

@leecow the preview 6 link is incorrect, should be https://github.com/dotnet/core/issues/8437 The same problem exists in preview 6/7 and rc1/2 issues

mairaw commented 1 year ago

Good catch @WeihanLi. I've fixed those.

JonDouglas commented 1 year ago

.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 commented 1 year ago

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

https://github.com/dotnet/runtime/issues/77514#issuecomment-1553414738 https://github.com/dotnet/runtime/issues/84321 https://github.com/dotnet/runtime/pull/86740

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

baronfel commented 1 year ago

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 commented 1 year ago

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.

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 commented 1 year ago

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 commented 1 year ago

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

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.

ivdiazsa commented 1 year ago

Alpine ASP.NET Docker Composite Images

Introducing a new flavor of ASP.NET Docker Images: The Composites.

What are the composite images?

As part of the containerization performance efforts, we are now offering a new ASP.NET Alpine-based Docker image with a composite version of the runtime in Preview 5. This composite is built by compiling multiple MSIL assemblies into a single R2R output binary. Due to having these assemblies embedded into a single image, we save jitting time and thus boosting the startup performance of apps. The other big advantage of the composite over the regular ASP.NET image is that the composites have a smaller size on disk. However, all these benefits don't come without a caveat. Since composites have multiple assemblies embedded into one, they have tighter version coupling. This means the final app run cannot use custom versions of framework and/or ASP.NET binaries embedded into the composite one.

Where can we get the composite images?

As of now, the composite images are available as preview in under the mcr.microsoft.com/dotnet/nightly/aspnet repo. The tags are listed with the -composite suffix in the official nightly Dotnet Docker page.

Future Work

Right now, the composites are only based on Alpine. Based on feedback as they start getting a more widespread adoption, we have plans to enable them for distroless images, and longer term bigger distros like Ubuntu and Debian.

JulieLeeMSFT commented 1 year ago

CodeGen

Community PRs (Many thanks to JIT community contributors!)

AVX-512

NativeAOT: Optimized ThreadStatic field access for GC-type

In preview 4, with PR#82973, we optimized the field accesses that are marked as ThreadStaticLocal for primitive types. With This PR#85619, we started optimizing the GC fields as well. This gave us some really good improvements in various microbenchmarks (133 on windows/arm64, 23 on windows/x64, 16, 13, 11 improvements).

Arm64

In preview 5, we enabled a few peephole optimizations:

General optimizations

elinor-fung commented 1 year ago

Runtime host determines RID-specific assets without RID graph by default

When running an application with RID-specific assets, the host determines which assets are relevant for the platform on which it's running. This applies to both the application itself and the resolution logic used by AssemblyDependencyResolver. By default in .NET 8, this determination will no longer use the RID graph, but will rely on a known list of RIDs based on how the runtime itself was built.

The RID graph has proven to be costly to maintain, difficult to understand, and generally fragile. This change is part of a longer-term goal to simplify our RID model.

You can read more about this change in the breaking change notice.

buyaa-n commented 1 year ago

.NET Libraries analyzers

Starting from .NET 8 preview 1, we have added several analyzers and code fixers that help developers verify correct and/or more performant usage of .NET Library APIs. We are thrilled to mention that most of these analyzers have been implemented by our community members. We would like to extend a big thank you to all our contributors for their hard work and dedication.

Analyzer proposal and the contributor Description Category Severity Help Link
Pass constants to parameters marked as [ConstantExpected] by @wzchua CA1856 fires when the ConstantExpected attribute not applied correctly on the parameter. CA1857 fires when a parameter annotated with the ConstantExpected attribute but the argument provided is not a constant, a constants should be used for optimal performance. Performance CA1856: Error CA1857: Warning CA1856, CA1857
Using StartsWith instead of IndexOf == 0 by @Youssef1313 It's more efficient and clearer to call String.StartsWith than to call String.IndexOf and compare the result with zero to determine whether a string starts with a given prefix. Performance Info ca1858
Recommend use of concrete types to maximize devirtualization potential by @geeknoid This rule recommends upgrading the type of specific local variables, fields, properties, method parameters, and method return types from interface or abstract types to concrete types when possible. Using concrete types leads to higher quality generated code by minimizing virtual or interface dispatch overhead and enabling inlining. Performance Info CA1859
Prefer .Length/Count/IsEmpty over Any() by @CollinAlpert It's more efficient and clearer to use Length, Count, or IsEmpty than to call Enumerable.Any extenion method to determine whether a collection type has any elements Performance Info CA1860
Extract array of const to static readonly field @steveberdy Constant arrays passed as arguments are not reused when called repeatedly, which implies a new array is created each time. If the passed array is not mutated within the called method, consider extracting it to a static readonly field to improve performance. Performance Info CA1861
Do not use OfType() with impossible types by @fowl2 Enumerable.Cast<T> and Enumerable.OfType<T> require compatible types to function expectedly. Enumerable.Cast<T> will throw InvalidCastException at runtime for elements of incompatible types. Enumerable.OfType<T> will never succeed with elements of incompatible types, resulting in an empty sequence. Widening and user defined conversions are not supported with generic types. Reliability Warning CA2021
Convert argument null checks to ArgumentNullException.ThrowIfNull by @stephentoub Throw helpers are simpler and more efficient than an if block constructing a new exception instance. With this analyzer four analyzers added for: ArgumentNullException, ArgumentException, ArgumentOutOfRangeException and ObjectDisposedException throw helpers Maintainability Info CA1510, CA1511, CA1512, CA1513

We plan to continue adding more analyzers to .NET 8 to help developers write better code and we are hoping for even more community contributions. This is a great opportunity for the community to add a new complete feature to .NET 8 SDK.

If you are interested in contributing, please check out our list of analyzers that are ready for development and marked up for grabs.

leslierichardson95 commented 1 year ago

Improve your productivity in VS Code with the C# Dev Kit extension!

The C# Dev Kit extension in VS Code is now available for public preview in VS Code! Designed to improve your C# productivity in VS Code, C# Dev Kit helps you manage your code with a solution explorer, write code faster with AI-assisted suggestions and completions, and gives you new capabilities to run and debug tests in the Test Explorer. Using a Roslyn-powered language service, C# Dev Kit also greatly improves performance of C# language features such as code navigation, refactoring, IntelliSense, and more.

To get started with C# Dev Kit, check out our recent announcement blog post.

omajid commented 1 year ago

Linux distribution-built (source-build) SDK now has the capability to build self-contained applications utilizing the source-build runtime packages.

I don't think this feature landed in Preview 5 itself. It was implemented during Preview 5 period, and it appears to be a part of the nightly Preview 6 builds, but I can't see it in Preview 5.

Preview 5:

$ ls -1 packs/
Microsoft.AspNetCore.App.Ref
Microsoft.NETCore.App.Host.fedora.38-x64
Microsoft.NETCore.App.Ref
NETStandard.Library.Ref

Preview 6 (nightly):

$ tar tf artifacts/x64/Release/dotnet-sdk-8.0.100-preview.6.23319.1-fedora.38-x64.tar.gz | grep './packs/' | cut -d/ -f-4 | sort -u
./packs/
./packs/Microsoft.AspNetCore.App.Ref/
./packs/Microsoft.AspNetCore.App.Ref/8.0.0-preview.6.23316.5
./packs/Microsoft.AspNetCore.App.Runtime.fedora.38-x64/
./packs/Microsoft.AspNetCore.App.Runtime.fedora.38-x64/8.0.0-preview.6.23316.5
./packs/Microsoft.NETCore.App.Host.fedora.38-x64/
./packs/Microsoft.NETCore.App.Host.fedora.38-x64/8.0.0-preview.6.23316.3
./packs/Microsoft.NETCore.App.Ref/
./packs/Microsoft.NETCore.App.Ref/8.0.0-preview.6.23316.3
./packs/Microsoft.NETCore.App.Runtime.fedora.38-x64/
./packs/Microsoft.NETCore.App.Runtime.fedora.38-x64/8.0.0-preview.6.23316.3
./packs/NETStandard.Library.Ref/
./packs/NETStandard.Library.Ref/2.1.0
JonDouglas commented 1 year ago

Complete via https://devblogs.microsoft.com/dotnet/announcing-dotnet-8-preview-5/