What's new in .NET 8 Preview 5 [WIP] #8436
Comments
|
Good catch @WeihanLi. I've fixed those. |
.NET Framework -> .NET 7 -> .NET 8 Benchmarks
// * Warnings * Simplified
Source: https://gist.github.com/jaredpar/f2fd4c87917ed0de73981a5ea410015e |
Enhancements to Metrics APIsIntroducing supplementary metrics APIs to cater to new use cases: DI Friendly metrics APIsIntroducing 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 TagsIntroducing 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);Referencesdotnet/runtime#77514 (comment) Please note that the newly exposed APIs are currently undergoing refinements, which may lead to minor changes in their current exposed form. |
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. |
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 in your |
|
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. |
SDK: Runtime-specific apps no longer self-contained by defaultSince .NET 6, specifying a runtime during publish has resulted in the following warning:
For .NET 8, we're finally taking the step of making this change. Going forward, for apps targeting
Apps targeting 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. |
Alpine ASP.NET Docker Composite ImagesIntroducing 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 Future WorkRight 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. |
CodeGenCommunity PRs (Many thanks to JIT community contributors!)
AVX-512
NativeAOT: Optimized ThreadStatic field access for GC-typeIn preview 4, with PR#82973, we optimized the field accesses that are marked as Arm64In preview 5, we enabled a few peephole optimizations:
General optimizations
|
Runtime host determines RID-specific assets without RID graph by defaultWhen 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. |
.NET Libraries analyzersStarting 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.
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 |
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. |
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: Preview 6 (nightly): |
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
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: #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
The text was updated successfully, but these errors were encountered: