June 10th, 2020

Announcing .NET 5.0 Preview 5

Rich Lander [MSFT]
Rich Lander [MSFT]
Program Manager

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 https://github.com/dotnet/docs/issues/18875. 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.

Closing

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.

Category
.NET

Author

Rich Lander [MSFT]
Rich Lander [MSFT]
Program Manager

Richard Lander is a Principal Program Manager on the .NET Core team. He works on making .NET Core work great in memory-limited Docker containers, on ARM hardware like the Raspberry Pi, and enabling GPIO programming and IoT scenarios. He is part of the design team that defines new .NET runtime capabilities and features. He enjoys British rock and Doctor Who. He grew up in Canada and New Zealand.

47 comments

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

Newest
Newest Popular Oldest
  • Pranav bhattarai

    Everything is connected to VS Studio.

    So, when is VS Studio coming to Linux distros? That’s the main question.

  • Stephen Cohen

    Will this new .NET run on the new XBox?
    (If this is a secret type of thing just ignore me)
    But I really want to know

  • Sebastiao C. Pereira

    I am curious about if Report Viewer in ASP NET will run with the new framework? Today Report Viewer does not run on ASP Net Core.

  • Jeff Johnson

    Still hoping you will find a way to get rid of the few remaining dll for WIndows single file executable, otherwise single file on Windows is no better than it is in .net core 3.1.

    You could extract the dll out of the exe dynamically to the temp path upon app start.

  • Charles Roddie

    Any timeline on when Xamarin iOS/Android/Mac will be testable on .Net 5?

  • Primož Ajdišek

    What are native exports? Is that anything related to external libraries?

  • Heinrich Moser

    Thanks, it’s very motivating to see the love and development effort going into .NET Core!

    Have you decided yet whether or not the RDLC->PDF report rendering engine will be ported to .NET Core? I know that the .NET Core team considers this to be a responsibility of the SQL Server team, but since this is a migration blocker for many developers (it’s currently #3 on the SQL Server suggestion user voice top list), I’m wondering if you know anything that we don’t.

    • Kathleen DollardMicrosoft employee

      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....

      Read more
    • Richard LanderMicrosoft employee

      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.

  • Daniel Smith

    Any plans to officially support Clear Linux?

    • Richard LanderMicrosoft employee

      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

        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

        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.

  • Jason Brower

    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...

    Read more
    • Richard LanderMicrosoft employee

      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...

      Read more
      • Jason Brower

        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

Read next