Announcing .NET 5.0 Preview 5

Rich Lander [MSFT]

Today, we’re releasing .NET 5.0 Preview 5. It contains a small set of new features and performance improvements. The .NET 5.0 Preview 4 post covers what we are planning to deliver with .NET 5.0. Most of the features are now in the product, but many are not yet in their final state. We expect that the release will be very close to feature-complete by Preview 7.

You can download .NET 5.0 Preview 5, for Windows, macOS, and Linux:

ASP.NET Core and EF Core are also being released today.

You need to use Visual Studio 2019 16.7 to use .NET 5.0. Install the latest version of the C# extension, to use .NET 5.0 with Visual Studio Code. .NET 5.0 isn’t yet supported with Visual Studio for Mac.

Release notes:

Following the release

It can be very hard to follow what the team is doing on GitHub, both in terms of specific features you might be interested in and understanding what the larger improvements are going to be in the next release. Even as the release blog writer, I find this difficult. To fix this problem, we put together a .NET 5.0 Runtime epics issue that you can use to navigate the big investments and themes in the release.

We consider an epic to be a collection of features that together form a step-function level improvement in .NET. If someone ever asks you “what’s in .NET 5.0?” or “is there anything in .NET 5.0 that we care about?”, this list of epics is a good place to start. However, it’s important to understand that there are many features that aren’t part of an epic and aren’t captured by this issue.

Do you like these “epic” issues? Would you like to see this pattern used in more dotnet org repos?

RyuJIT improvements

The following improvements were made to the RyuJIT JIT compiler:

Native exports

We’ve had requests to enable exports for native binaries that calls into .NET code for a long time. It’s a great scenario, and we’re now enabling it with .NET 5.0. The building block of the feature is hosting API support for UnmanagedCallersOnlyAttribute.

This feature is a building-block for creating higher level experiences. Aaron Robinson, on our team, has been working on a .NET Native Exports project that provides a more complete experience for publishing .NET components as native libraries. We’re looking for feedback on this capability to help decide if the approach should be included in the product.

The native exports project enables you to:

  • Expose custom native exports.
  • Doesn’t require a higher-level interop technology like COM.
  • Works cross-platform.

There are existing projects that enable similar scenarios, such as:

[Breaking change] Removal of built-in WinRT support in .NET 5.0

Note: This change is coming in Preview 6. This is an early announcement.

Windows Runtime (WinRT) is the technology and ABI that new APIs are exposed with in Windows. You can call those APIs via .NET code, similar to how you would with C++. Support for WinRT interop was added in .NET Core 3.0, as part of adding support for Windows desktop client frameworks (Windows Forms and WPF).

More recently, we’ve been working closely with the Windows team to change and improve the way that WinRT interop works with .NET. We have replaced the built-in WinRT support with the C#/WinRT tool chain, provided by the Windows team, in .NET 5.0. This change in WinRT interop is a breaking change, and .NET Core 3.x apps that use WinRT will need to be recompiled. We will provide more infromation on this in coming previews.

The benefits are called out in Support WinRT APIs in .NET 5:

  • WinRT interop can be developed and improved separate from the .NET runtime.
  • Makes WinRT interop symmetrical with interop systems provided for other operating systems, like iOS and Android.
  • Can take advantage of many other .NET features (AOT, C# features, IL linking).
  • Simplifies the .NET runtime codebase (removes 60k lines of code).

For more details, see the official docs issue at To see all breaking changes (in dotnet/runtime) in the release, check out the .NET 5.0 breaking change query.

Expanding System.DirectoryServices.Protocols to Linux and macOS

We’ve been adding cross-platform support for System.DirectoryServices.Protocols. In Preview 5, we’ve added support for Linux and we’ll add support for macOS in Preview 6. Windows support was pre-existing.

System.DirectoryServices.Protocols is a lower-level API than System.DirectoryServices, and enables (or can be used to enable) more scenarios. System.DirectoryServices includes Windows-only concepts/implementations, so it was not an obvious choice to make cross-platform. Both API-sets enable controlling and interacting with a directory service server, like LDAP or Active Directory.

Alpine 3.12

We added support for Alpine 3.12, for .NET Core 3.1 and .NET 5 this week. The maintainers of Alpine Linux announced the release of Alpine 3.12 on May 29th. We’re working on adding support for new Linux distro versions more quickly and predictably than what we’ve done in the past.  We’ve heard feedback that it is important that you have access to .NET on new versions of Alpine, Debian, Ubuntu and others as quickly as possible.

You can see that we’ve started using a new model of posting an issue for a new distro version before it is released. That’s what we did with Alpine 3.12. In future, we plan to post these issues much earlier. For example, the next distro release we need to track will probably be Ubuntu 20.10. We haven’t yet decided, but we will likely post a similar issue for that release in July or August in preparation for an October release of the new Ubuntu version.


Thanks to everyone for feedback on .NET 5.0 previews and for your early feedback. As I suggested in the introduction to the post, we’re about half-way through the release now. Most of the features are now included, but there are still many changes that we expect in the next few previews to complete experiences and round off rough edges that still exist. Take care.


Discussion is closed. Login to edit/delete existing comments.

  • Juri Ryazanov 0

    AOT native compilation not happening?

    • Anthony Foxclaw 0

      I’m assuming it could arrive by Preview 6. Native exports feels like a preliminarily to AOT native.

      • Richard LanderMicrosoft employee 0

        We will have more to say about AOT and single file, for preview 7.

        • James Wil 0

          We need proper native aot compilation.. that is the only thing dotnet is lacking and failing behind.. we are forced to use something else when we need to target specific scenarios that requires minimal footprint..

          • James Wil 0

            mono full aot with llvm, i hope that is what you’ll mention, because that project looks really nice

    • Max Mustermueller 0

      When I heard about AOT plans I was SUPER excited as this is a game changer for .NET and the most exciting feature I was ever looking for since more than 8 years now.

      However with latest Xamarin Forms announcement and mono integration I have some bad feelings that AOT will be super limited, like it only works with Xamarin and / or console or library projects but not with Winforms / WPF. Which then, makes AOT pretty much useless for my scenarios.

      Let’s hope AOT will be available for everything that .NET (Core) supports now finger crossed.

      • Rahim Surani 0

        You are absolutely right!

        I am also waiting for the AOT compilation for our Winforms application to build native app. Now we are using obfuscation to protect our codes which is not perfect solution.

        I am surprised to know that AOT is not in this current preview version.

        This MSIL compiled exe is like deploying source codes on client’s machine, why Microsoft is not taking it seriously.

    • Andrew Witte 0

      Yes Win32, macOS and Linux AOT targets are what I’m looking to more than anything.
      Will Mono => LLVM or CoreRT be used for this? I’m guessing even if Mono => LLVM is used, eventually CoreRT will replace it?

  • Rojan Gh. 0

    No Java interop then?

    • Richard LanderMicrosoft employee 0

      Not with .NET 5.0. We have had to scope the release due to the pandemic.

  • Damian Wyka 0

    Regarding epics in github: maybe stick them like you sticked infrastructure topic etc? This will make them easily discoverable. If too many epics to stick, consider making one epics mega-thread with links to all active epics and stick this one mega-thread

      • Richard LanderMicrosoft employee 0

        I understand now. I pinned the 5.0 epic for you. Got it. Great idea!

        • Damian Wyka 0

          Yeah this is exactly what i was thinking about. Thanks

  • Daniel Frank 0

    The optional runtime switch, from CoreCLR to Mono, will be available for .NET 5?

    • Richard LanderMicrosoft employee 0

      .NET 6.0.

      Can you tell me which scenario you’ll use that for?

      • Michal Dobrodenka 0

        I have many ARMv6 embedded devices as well as ARMv7. All of them currently running on mono but I would like to switch to .NET. It’s possible with ARMv7 devices but not with ARMv6, so I still have to support mono.

        Main reason for switch is not performance (which I found that mono is sometimes faster and memory usage about the same in my case) but bugs in mono network code. That really sucks. (In some networks I have to change TCP MTU size because mono is not able to communicate – python & dotnet without problems. Memory leaks in SSL Streams. UDP problems. etc) Most of the bugs encountered in mono for 9 years I’m working with it are in network code.

      • Daniel Frank 0

        I’m curious to try mono runtime on AWS Lambda.
        Don’t get me wrong, 3.1 CoreCRL runtime works just fine on it (almost 40% better cold starts in some scenarios), but
        in composite function calls like Step functions, the summing of startups is still a little bit anoing.
        An most simple and smaller runtime can do this kind of job better, i think, (throughput is not a concern here, due the Lambda’s scalability behaviour).
        Another problem is AWS lambda runtime update policy, she only updates for LTS versions. Mono plus Lambda’s custom runtime probaly can aford this limitation (maybe CoreCLR can do that too, but based on 3.1 version, a self contained bundle perform worst).

        • Charles Roddie 0

          Sounds like you are looking for AOT support rather than mono.

          • Daniel Frank 0

            Maybe. R2R in 3.1 brings a great improvement, Mono full AOT can bring a step further.
            Yeah, it’s appears We’re walking the AOT path, just one step at time.

      • Andrew Witte 0

        Mono still supports ARMv6 && MIPS32 && MIPS64 && PPC I believe (like the older .NET CF did I think).
        Seems there is a Chinese company porting .NET Core to MIPS64 but not MIPS32.

        IDK why .NET takes so long to port when other runtimes do not. Seems like a possible area to improve.

  • mariobot 0

    Hi, I dont understand the Apline update. Some came tell where find more information about that topi.

  • Jose Felix 0

    Hi I cannot run my grpc code .net preview5
    , what’s is the state of grpc on this previews?

    • Sourabh Shirhatti Microsoft employee 0

      There have been no changes to gRPC in this preview. Do you mind filing an issue at with more information? We can help you further investigate.

  • Paulo Pinto 0

    Nice to know about the native exports scenarios.

    I always felt that .NET had a missed opportunity not allowing for such scenarios since the early days, meaning a having feature parity with C++ for all native deployment scenarios where the use of a GC based language is possible.

    Nice to see such scenarios being embraced (AOT, native exports,..).

    On that note, and due to the C#/WinRT reference, any news on the future of .NET Native and 100% to Windows APIs from .NET?

    As .NET developer, it would be nice not having to reach out to C++ for UWP APIs only accessible via C++ (e.g. DirectX), specially now that C++/WinRT (with lesser tooling capabilities) is the official replacement for C++/CX going forward.

    Nevertheless, good work.

    • Richard LanderMicrosoft employee 0

      Glad you like the direction.

      I’ll try to cover your questions. Tell me where I don’t do that well enough.

      • No changes planned for .NET Native.
      • You can call (almost) all Windows APIs today with .NET Core, either Win32 or WinRT.
      • Consuming C++ types in .NET is a challenge. That’s where C++/CLI comes in.
      • DirectX has multiple solutions, like Win2D, SharpDX, and SharpGenTools.

      Does that help?

      • Paulo Pinto 0

        Thanks for answering me.

        C++/CLI is not a complete solution and it is Windows only, while C++/CX has been deprecated by C++/WinRT. However C++/WinRT tooling is found lacking versus the C++/CLI and C++/CX alternatives, namely no VS support for IDL files (syntax highlighting and completion), requires manually copying generated files and integrating them into VS projects, and some manual boilerplate for XAML integration.

        SharpDX project and SharpGenTools are no more, the author has moved into something else, meanwhile Managed DirectX and XNA, are no more. Naturally one can discuss the idea of making use of a game engine instead, although maybe not the best way for LOB applications.

        What is the state of Win2D actually? So far it seemed more to be an open source project done by some Microsoft employees, but far from being the official 2D Canvas API for WinUI/UWP applications.

        I happen to be coding for Windows since the Windows 3.0 days, so I can always go down into C++land when dealing with nano-COM APIs that I need to access from .NET, however not every .NET developer has such skill set, hence why I think it would be a nice productivity boost if .NET had more parity with C++ in platform APIs.

        • Gavin Williams 0

          I agree. As someone using SharpDX. .Net 5 is a road block, there’s no way forward. There’s no compatibility there. And besides, every year, without official MS support, SharpDX is becoming more and more out of date with respect to DirectX and Windows API’s.

          C++/WinRT is extremely difficult to use compared to C++/CX or C# WinRT Components.

          What I would love to see is an easy way for C# dev’s to write native code and interop with native code and DirectX. C++/CX and WinRT was a move in the right direction. But there’s no follow through, CX is killed, and DirectX hasn’t been rewritten to allow language interop.

          The picture for consuming C++ and DirectX is much worse today for C# dev’s compared to a few years ago. That’s the wrong direction to be going, it should be getting easier to write high performance engine and graphics code from C#, not harder.

          And I mean harder for the average developer who doesn’t have the time to invest in complicated C++ interop solutions just to replace existing tools. Obviously when you’re an experienced C++ engineer surrounded by other engineers with a solution for every problem it might not seem like it’s too hard to get some C++ WinRT Components working to wrap DirectX. But for me for instance, I’m making a game by myself, and it’s taking much longer than I would like as it is. It’s not viable to make a replacement for SharpDX.

          I can finish this project with SharpDX but I don’t really want to be using it beyond that as I want to be using .Net 5 – I’m using UWP Core & Xaml framework currently.

          Anyway. I think bringing C# dev frameworks back together under .Net 5 is really exciting anyway. And maybe it will pave the way for better solutions for interop in the future

  • Jason Brower 0

    I jumped from NetCore 3.x to .Net 5 prev 4 then to .Net 5 prev 7 back down to .Net 5 prev 5 just before this announcement.

    When I went from Core 3.x to .Net 5 the two biggest changes I had to make were related to TFMs and MessagePack jumping from 1.x to 2.x. MessagePack aside, the challenging part about the TFM changes was the availability of guidance on upgrading NetStandard vs Platform Specific NetCore. I had initially read the spec that you mentioned in the epic (epics are awesome BTW, really informative). Since I knew I had to change the TFMs, I made the poor judgment of assuming the full TFM spec had been implemented. So I took the 149 assembly projects I’m working with and migrated .NetStandard to net5.0 and NetCore projects to .net5.0-windows. This of course wouldn’t compile because the .net5.0-windows TFM did not exist. I then changed everything to .net5.0 and it compiled. The only difference between my prior NetStandard projects vs prior netcoreapp TFM projects that remains is the different SDK that each csproj references at the top. I’m thankful for that remaining difference because when the full TFM spec has been implemented, it’s that difference that I will use to determine which projects need to reference net5.0-windows TFM (although it sounds like the framework will throw a warning in the future if I reference a platform specific component in a net5.0 TFM project ??).

    When I grew brave and then jumped into the not yet released preview 6/7 builds the next challenge was part of your announcement today. That is how I switched from calling the built-in Windows 10 API projections to the ones over in the independent repository. Thankfully members of your companies runtime team were extremely helpful and ultra responsive to the questions I posted. They were communicating with me on Saturday/Sunday (made me feel good that I wasn’t the only one working) regarding the PointOfService namespace calls I was making into the prior projections as wells as pointing me to the quickest way back running against the yet to be released preview 5 that you announced here.

    On a final note it looks like we no longer need to use Visual Studio preview to use .Net 5.0. I think I accidentally discovered this over the weekend or so when I launched my solution from PowerShell 7 and the default VS exe was the latest official non pre-release. Later that day I thought, hmmm, I’m not using pre-release Visual Studio, why is this working? LOL. To avoid risk I switched back to pre, but after reading your post I had an “aha” moment.

    It’s a really exciting time to be a .Net developer; hard to keep up (for those of us who have always tried out pre-releases) but exciting nonetheless. The fact that it’s hard to keep up is a compliment to what Microsoft is doing. Still keeping LTS on Core 3.x but plowing forward for those ready to take the wild journey.

    • Richard LanderMicrosoft employee 0

      Wow. I had to belt-in to get through all that. I think we can say you are an early adopter. Nice.

      Yes, many folks on the team are super helpful. Kudos to them for helping you out.

      We’re working through a lot of the flows that you are exercising right now. It would probably be easier to work with you directly, and use your projects as a kind of test case to ensure we’ve got all your scenarios covered. Works? You can start with me at rlander@ms.

      Glad you like the epics model. That’s new (as you know). We’ve got a few new initiatives we’re working on to make it easier, more intuitive and more fun to navigate and participate in the dotnet repos. I just need to finish some write-ups before I share them.

      • Jason Brower 0

        Thank you for your kind reply. Ironically Aaron Robinson had asked me to contact him and when he replied to my email, you were copied in on that communication. I am about to reply to that email, will have it out this afternoon. Thank you again, Jason Brower Oceanside Software

  • Daniel Smith 0

    Any plans to officially support Clear Linux?

    • Richard LanderMicrosoft employee 0

      None currently. We had the same request from one Microsoft team, too. We’re waiting for more requests to motivate supporting Clear Linux, or any other distros. Keep the feedback coming.

      • Daniel Smith 0

        Clear Linux blows just about every other distro out of the water in almost all of the benchmarks I’ve seen recently (e.g. check out the latest benchmarks on Phoronix), so it would be interesting to see what kind of performance scores you could get out of .NET 5 with it 🙂

        • Richard LanderMicrosoft employee 0

          Yes, I’ve seen those and know some of the back story on Clear Linux. The other Microsoft team we talked to said very similar things to us 😉

          We’re happy to consider supporting it as we get a growing number of requests for it. It sounds promising.

    • Richard LanderMicrosoft employee 0

      Thanks for the kind words about the release. Just want to say that these releases are the work of hundreds of people, many thousands of hours of effort, and a metric ton of design decisions. It’s my real privilege to get to write about the product each release.

      I’ll leave the VB question to Kathleen.

    • Kathleen DollardMicrosoft employee 0

      I’m glad you’re looking forward to .NET 5 support for Visual Basic!!

      The full end to end experience will not be available until late in the .NET 5 cycle. Specifically, the Project Properties dialog is used in VB to manage a .myapp file that is used to generate the Application Model support. Today in .NET 5, you have to edit the .myapp file by hand to use the Application Model, and we suspect many people use the Application Model, particularly for WinForms. Thus, the Visual Basic experience isn’t good enough yet for us to call out in a blog post. There’s also an issue that double clicking controls in WinForms doesn’t find the handler, so tends to create a new incorrect handler.

      Also, there aren’t templates because we use that to signal that a feature is ready, and VB clearly isn’t due t to the remaining issues.

      Other than these issues, you can use Visual Basic in .NET 5 today. VB also works in earlier versions of .NET Core, with increasing support in each version.

Feedback usabilla icon