Skip to content

What's new in .NET 7 Preview 3 [WIP] #7108

Closed
Closed
What's new in .NET 7 Preview 3 [WIP]#7108
Labels
documentation

Description

@leecow
leecow
opened on Jan 11, 2022

What's new in .NET 7 Preview 3

This issue is for teams to highlight work for the community that will release .NET 7 Preview 1

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

## 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 using the feature.

Preview 1: #7106
Preview 2: #7107
Preview 3: #7108
Preview 4: #7378
Preview 5: #7441
Preview 6: #7454
Preview 7: #7455

Activity

  1. leecow
    added
    documentation
    on Jan 11, 2022

  2. tarekgh commented on Mar 4, 2022

    @tarekgh
    tarekgh
    on Mar 4, 2022
    Member

    Observability

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

  3. tarekgh commented on Mar 16, 2022

    @tarekgh
    tarekgh
    on Mar 16, 2022
    Member

    System.Composition.Hosting

    Providing APIs to allow adding a single object instance to the System.Composition.Hosting container. Similar to the functionality provided in the legacy interfaces System.ComponentModel.Composition.Hosting with the API ComposeExportedValue(CompositionContainer, T)

    dotnet/runtime#29400

    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);
    }
}

  4. janvorli commented on Mar 31, 2022

    @janvorli
    janvorli
    on Mar 31, 2022
    Member

    Startup time improvements with Write-Xor-Execute enabled

    The dotnet/runtime#65738 reimplemented the precode and call counting stubs (tiered compilation helper stubs) to significantly reduce number of post-creation modifications of executable code in the runtime. This resulted in 10-15% startup time improvements.

    As a bonus, this change also resulted in steady state performance improvements (upto 8%) in some microbenchmarks and some ASPNet Benchmarks even without Write-Xor-Execute enabled.

    However, there are few regressions resulting from that change too (without Write-Xor-Execute enabled) that will be addressed in the upcoming preview releases. These were observed in the Orchard and Fortunes benchmarks on Intel processors only.

  5. JulieLeeMSFT commented on Apr 1, 2022

    @JulieLeeMSFT
    JulieLeeMSFT
    on Apr 1, 2022
    Member

    CodeGen

    Community PRs (Many thanks to JIT community contributors!!)

    From @clamp03

    From @SkiFoD

    From @sandreenko

    From @SingleAccretion

    Form @trympet

    From @Wraith2

    Dynamic PGO

    Arm64

    Loop Optimizations

    General Optimizations

  6. mangod9 commented on Apr 6, 2022

    @mangod9
    mangod9
    on Apr 6, 2022
    Member

    GC Regions Enabled by default

    With Preview 3, regions functionality which should help with memory utilization for high throughput applications has been enabled by default. The functionality is now enabled for all Platforms except MacOS and NativeAOT (which would be enabled in the future). More details are available in this issue: dotnet/runtime#43844

    We expect some working set increases for smaller applications due to how regions are initially allocated. If you notice any functional or performance differences please create an issue within the runtime repo.

  7. agocke commented on Apr 8, 2022

    @agocke
    agocke
    on Apr 8, 2022
    Member

    NativeAOT Update

    In the .NET 7 Preview 2 blog post, we announced that the NativeAOT project has been moved out of experimental status and into mainline development in .NET 7 in the dotnet/runtime repo. We know that many of you have been eagerly awaiting updates from the team on what’s coming for NativeAOT, and we have a couple of new updates for you for Preview 3!

    If you want details about NativeAOT, or to jump in and get started with it, the repo docs are the best place for that.

    We also recognize that some of you might not be familiar with what NativeAOT is, so we wanted to share a quick overview of it with you.

    What is NativeAOT?

    AOT, ahead-of-time compilation, refers to an umbrella of technologies which generate code at application build time, instead of run-time. AOT is not new to .NET Core - we ship ReadyToRun for client and server scenarios, and Mono AOT for Mobile and WASM. NativeAOT brings full native pre-compilation to .NET Core desktop client and server scenarios. NativeAOT is not replacing these existing technologies, rather offering a new set of capabilities that unlocks new form factors.

    Existing AOT-compiled .NET assemblies contain platform-specific data structures and native code to frontload work typically done at runtime. Precompiling these artifacts saves time at startup (e.g. ReadyToRun), and enables access to no-JIT platforms (e.g. iOS). If precompiled artifacts are not present, .NET either falls back to JIT or interpretation (depending on the platform).

    NativeAOT is similar to .NET Core’s existing AOT technologies, but it produces only native artifacts. In fact, the NativeAOT runtime does not know how to read the .NET assembly file formats - everything is platform-native; the executable file format parsing is fully handled by the underlying operating system.

    The main advantage of NativeAOT is in startup time, memory usage, accessing to restricted platforms (no JIT allowed), and smaller size on disk. Applications start running the moment the operating system pages in them into memory. The 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. NativeAOT is best suited for environments where startup time matters the most. Targeting NativeAOT has stricter requirements than general .NET Core applications and libraries. NativeAOT forbids emitting new code at runtime (e.g. Reflection.Emit), and loading new .NET assemblies at runtime (eg. plug-in models).

    Prepare your apps for NativeAOT

    For .NET 7 we are targeting console apps and native libraries as the primary scenario for NativeAOT. Application developers and library authors can now take advantage of NativeAOT by ensuring that their applications are trimmable. Since trimming is a requirement for NativeAOT compilation, preparing your applications and libraries now for trimming will help them get ready for NativeAOT as well. If you are an author of any .NET libraries, following the “Trimming libraries” instructions specifically will help you prepare your libraries for trimming and NativeAOT.

    One of the apps that we're planning to ship in .NET 7 compiled with NativeAOT is the crossgen tool. Crossgen is part of the .NET SDK - it's the CoreCLR AOT compiler that produces ReadyToRun executables. Crossgen is written in C# and we currently ship it compiled with itself as a ReadyToRun app (it's turtles all the way down!). We're already seeing some very promising numbers in terms of compilation speed and size. Crossgen benefits heavily from NativeAOT because it's a short-lived process and the startup overhead dominates the overall execution time:

    Scenario ReadyToRun NativeAOT
    Compile CoreLib 4182 ms 3512 ms
    Compile HelloWorld 185 ms 49 ms
    Configuration Size
    ReadyToRun 34.8 MB
    NativeAOT 17.6 MB

    Looking ahead, NativeAOT compatibility will be improved over the next few versions of .NET, however there will always be reasons to prefer JIT for many scenarios. We will also add first-class support in the dotnet SDK for publishing projects with NativeAOT.

  8. sajjadarashhh commented on Apr 9, 2022

    @sajjadarashhh
    sajjadarashhh
    on Apr 9, 2022

    thanks to .net team for amazing features in each update.
    i have one question we can use nativeAot in blazor wasm!?

  9. srxqds commented on Apr 10, 2022

    @srxqds
    srxqds
    on Apr 10, 2022

    thanks to .net team for amazing features in each update. i have one question we can use nativeAot in blazor wasm!?

    i think it can't got from this dotnet/runtime#45471 (comment)

  10. bartonjs commented on Apr 11, 2022

    @bartonjs
    bartonjs
    on Apr 11, 2022
    Member

    Cryptography: Generating X.500 names more robustly

    dotnet/runtime#44738

    Classically, anyone wanting to build a X.500 name (such as for creating test certificates with the CertificateRequest class did so with string manipulation, either via a simple literal or with string formatting, e.g.

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

    This is generally fine, except for when subjectName contains a comma, quote, or anything else that has an influence on the parser. To address that, we added the X500DistinguishedNameBuilder class. Because every method only operates on a single relative distinguished name (RDN), there's no ambiguity in parsing. As a bonus, since the RDN identifiers are expanded, 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(), ...);

  11. bartonjs commented on Apr 11, 2022

    @bartonjs
    bartonjs
    on Apr 11, 2022
    Member

    Cryptography: EventSource for X509Chain on Linux

    X.509 certificate chain building has a lot of pieces and moving parts. While it reports detailed reasons for failure as part of the API, sometimes it's useful when diagnosing issues to see when something happened, or how long it took, et cetera. On Windows the logging is done by the OS, as part of "CAPI2 Diagnostics", but on Linux we had no equivalent. Starting in .NET 7 Preview 3 the traces are produced by the System.Security.Cryptography.X509Certificates.X509Chain.OpenSsl event source. These two collected trace runs, at full verbosity, show the performance benefit of caching certificate revocation lists (CRLs) during chain building operations.

    2022-04-11T16:05:24.164Z: ChainStart - Starting X.509 chain build.
2022-04-11T16:05:24.344Z: FindFirstChainFinished - First build finished with status 0.
2022-04-11T16:05:24.352Z: RevocationCheckStart - Starting revocation check in mode 'Online' with scope 'ExcludeRoot' on a 3-element chain.
2022-04-11T16:05:24.379Z: CrlIdentifiersDetermined - Certificate 'CN=microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US' has a CRL Distribution Point of 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20TLS%20Issuing%20CA%2006.crl', will use '12fa6c3e.efbe5079.crl' as the cache file.
2022-04-11T16:05:24.380Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:24.412Z: CrlCacheExpired - The cached CRL's nextUpdate value (2022-04-11T09:05:23.9500496-07:00) is not after the verification time (2022-03-27T14:28:22.0000000-07:00).
2022-04-11T16:05:24.414Z: CrlCacheCheckStop - Duration 33.851ms
2022-04-11T16:05:24.433Z: AssetDownloadStart - Starting download of certificate asset uri 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20TLS%20Issuing%20CA%2006.crl' with a 15000ms timeout.
2022-04-11T16:05:24.700Z: AssetDownloadStop - Asset download finished with a 1249-byte response. - Duration 267.098ms
2022-04-11T16:05:24.760Z: CrlCacheWriteSucceeded - The downloaded CRL was successfully written to the cache.
2022-04-11T16:05:24.760Z: CrlIdentifiersDetermined - Certificate 'CN=Microsoft Azure TLS Issuing CA 06, O=Microsoft Corporation, C=US' has a CRL Distribution Point of 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl', will use '607986c7.8ab5229e.crl' as the cache file.
2022-04-11T16:05:24.760Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:24.777Z: CrlCacheExpired - The cached CRL's nextUpdate value (2022-04-11T09:05:23.9500496-07:00) is not after the verification time (2022-04-06T12:54:50.0000000-07:00).
2022-04-11T16:05:24.778Z: CrlCacheCheckStop - Duration 17.566ms
2022-04-11T16:05:24.778Z: AssetDownloadStart - Starting download of certificate asset uri 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl' with a 15000ms timeout.
2022-04-11T16:05:24.814Z: AssetDownloadStop - Asset download finished with a 877-byte response. - Duration 36.113ms
2022-04-11T16:05:24.843Z: CrlCacheWriteSucceeded - The downloaded CRL was successfully written to the cache.
2022-04-11T16:05:24.847Z: CrlChainFinished - With CRLs applied, the chain build finished with status 0.
2022-04-11T16:05:24.848Z: RevocationCheckStop - Duration 496.299ms
2022-04-11T16:05:24.852Z: ChainStop - Duration 688.635ms

    2022-04-11T16:05:50.392Z: ChainStart - Starting X.509 chain build.
2022-04-11T16:05:50.572Z: FindFirstChainFinished - First build finished with status 0.
2022-04-11T16:05:50.580Z: RevocationCheckStart - Starting revocation check in mode 'Online' with scope 'ExcludeRoot' on a 3-element chain.
2022-04-11T16:05:50.608Z: CrlIdentifiersDetermined - Certificate 'CN=microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US' has a CRL Distribution Point of 'http://www.microsoft.com/pkiops/crl/Microsoft%20Azure%20TLS%20Issuing%20CA%2006.crl', will use '12fa6c3e.efbe5079.crl' as the cache file.
2022-04-11T16:05:50.609Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:50.625Z: CrlCacheAcceptedFile - The cached crl nextUpdate value (2022-04-21T06:28:22.0000000-07:00) is acceptable, using the cached file.
2022-04-11T16:05:50.626Z: CrlCacheCheckStop - Duration 17.139ms
2022-04-11T16:05:50.633Z: CrlIdentifiersDetermined - Certificate 'CN=Microsoft Azure TLS Issuing CA 06, O=Microsoft Corporation, C=US' has a CRL Distribution Point of 'http://crl3.digicert.com/DigiCertGlobalRootG2.crl', will use '607986c7.8ab5229e.crl' as the cache file.
2022-04-11T16:05:50.633Z: CrlCacheCheckStart - Checking for a cached CRL.
2022-04-11T16:05:50.633Z: CrlCacheAcceptedFile - The cached crl nextUpdate value (2022-04-27T13:40:47.0000000-07:00) is acceptable, using the cached file.
2022-04-11T16:05:50.633Z: CrlCacheCheckStop - Duration 0.177ms
2022-04-11T16:05:50.635Z: CrlChainFinished - With CRLs applied, the chain build finished with status 0.
2022-04-11T16:05:50.635Z: RevocationCheckStop - Duration 54.661ms
2022-04-11T16:05:50.637Z: ChainStop - Duration 245.381ms

  12. kouvel commented on Apr 12, 2022

    @kouvel
    kouvel
    on Apr 12, 2022

    System.Threading

    The managed implementation of the thread pool is now used by default for handling IO completions on Windows. IO completions are queried in batches on fewer threads, which can be a bit more efficient, and are processed at higher priority in the same worker thread pool to reduce oversubscription.

    If SocketTransportOptions.UnsafePreferInline is being used, that can be worked around after this change by also using DOTNET_SYSTEM_NET_SOCKETS_INLINE_COMPLETIONS=1 as described there.

    The previous implementation of IO completion handling can be restored by setting the environment variable DOTNET_ThreadPool_UsePortableThreadPoolForIO=0 before starting the app.

  13. AustinWise commented on Sep 18, 2022

    @AustinWise
    AustinWise
    on Sep 18, 2022
    Contributor

    System.Threading

    * [Add support for Windows IO completions to the portable thread pool runtime#64834](https://github.com/dotnet/runtime/pull/64834)

    This appears to have not made it into the blog post. The only mention of the new threadpool features I could find on the blog was in the performance improvements post. And this issue is the only hit on Google for the new DOTNET_ThreadPool_UsePortableThreadPoolForIO config.

    Should this change be documented or publicized like how the portable thread pool was announced in the blog post for .NET 6 preview 1? It's a cool feature!

  14. leecow commented on Jan 24, 2023

    @leecow
    leecow
    on Jan 24, 2023
    MemberAuthor

    .NET 7 GA is available. Closing these pre-release issues.

  15. leecow
    closed this as completedon Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentation

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions