Announcing .NET 5.0 Preview 5

Avatar

Richard

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.

47 comments

Comments are closed. Login to edit/delete your existing comments

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

  • Jeff Johnson
    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.