Announcing .NET 5.0 Preview 6

Rich Lander [MSFT]

Today, we’re releasing .NET 5.0 Preview 6. 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 some are not yet in their final state. We expect that the release will be feature-complete with Preview 8.

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

ASP.NET Core and EF Core are also being released today. Note: EF Core 5.0 will not support .NET Standard 2.0 or .NET Framework. Read the EF Core post to learn more.

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

Release notes:

Windows ARM64 Update

We announced support for Windows ARM64 as part of Preview 4. At that time, we had only enabled console and ASP.NET Core apps on Windows ARM64. The Preview 6 SDK now includes support for Windows Forms. That means you can build and run Windows Forms apps on Windows ARM64 devices, just like you would on x64. We’re still working on adding support for WPF on Windows ARM64.

You can see a sample Windows Forms app running on an ARM64 laptop, shown below.

2020-05-13

Visual Studio .NET remote debugger support for Windows ARM64 is expected with Visual Studio 16.7. We expect Visual Studio Code .NET remote debugger support to follow soon after that. To avoid confusion, this support is referring to running Visual Studio or Visual Studio Code on an x64 machine, and remote attaching to a running .NET application on a Windows ARM64 machine. In addition, Visual Studio Code is adding support for ARM64. We will support the C# extension and the .NET debugger running within the Windows ARM64 version of Visual Studio Code, however, I don’t have dates to share yet for that.

Windows Forms

Visual Basic users are used to being able to enforce that their applications are single-instanced (one instance launched at a time). This behavior is now available via WindowsFormsApplicationBase.IsSingleInstance. Here’s a great explanation of this behavior from Scott Hanselman. Credit: @paul1956

The team added Collapse Support to ListViewGroup. This change makes it easier to manage a form with multiple ListViewGroups. Credit: @lonitra (.NET Team intern).

You can see the result shown below.

collapse2

RyuJIT code quality improvements

The RyuJIT team continues to land really important improvements, preview after preview. They didn’t disappoint with Preview 6. Let’s take a look:

Single file apps

We’ve been continuing to improve Support Single-File Apps in .NET 5 . Our goal is to enable publishing an app as one file (obviously), for Windows, macOS and Linux. We’re almost there. When we last talked about single file, with Preview 4, I mentioned that Windows “single file” apps required a few extra runtime files. We added a new option to include native binaries and any additional content (like images) in the single-file. These files will be extracted upon first launch. Apps that target Linux and macOS don’t need to use this option for native runtime binaries, unless they want to use it for media or other content.

Current limitations:

  • On Linux, the singlefilehost with runtime components linked in is still to be implemented. Therefore, the runtime native binaries will be published as separate files (similar to Windows experience). #37119 , #38304
  • On Linux, ready-to-run assemblies embedded in a bundle are loaded like IL assemblies. #38061

Native hosted application

Over the years, we’ve seen a variety of hosting models for .NET in native applications. @rseanhall proposed and implemented a novel new model for doing that, which takes advantage of all the built-in application functionality offered by the .NET application hosting layer (specifically loading dependencies), while enabling a custom entrypoint to be called from native code. That’s perfect for a lot of scenarios, and that one can imagine becoming popular with developers that host .NET components from native applications. That didn’t exist before. Thanks for the contribution, @rseanhall.

Two primary PRs:

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

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

Platform support

We’ve updated our .NET 5 – Supported OS versions page to capture our latest plans for platform support for .NET 5.0. Please tell us what you think. What are we missing?

We realized that the package manager and container support we offer isn’t listed on that page. That should be fixed. We plan to add that information before we release .NET 5.0.

Closing

We’re now past the half-way point in this release cycle. In fact, we’re starting to (in our parlance) “close down the release”. If you are watching our repos closely, you’ll see that we’re starting to manage the milestones of issues more carefully. Having worked on multiple .NET releases now, I can tell you that this is a great time. It’s time to claim victory on the set of features we’ve built, and to polish them to the point that you are happy using them. That’s what we’re doing now, in our home workplaces.

24 comments

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

  • Tony Henrique 0

    I am installing it right now!

  • Daniel Smith 0

    Any news on the SSRS ReportViewer control for WinForms? Reporting is super critical for many business applications out there, and currently a blocker for moving to .NET Core.

    If MS is short on resources to migrate it, I’m sure the community would be willing to help out if you put the source code up on GitHub 🙂

    • Jeremy LiknessMicrosoft employee 0

      Hi,

      Currently there is no plan to build/migrate the SSRS ReportViewer control for WinForms. The current focus for visualization is PowerBI. It is possible to convert RDLC files to RDL (see here) and migrate RDL to Power BI (see here). I will take up the source code suggestion with the team.

      -Jeremy

      • Daniel Smith 0

        Thanks Jeremy. I hadn’t looked at Power BI in a while, and didn’t realise support for paginated reports was added last year. It looks like migration of my existing RDL reports is relatively straight forward, so I’m happy to do that if SSRS is being wound down.

        The sort of things most of my desktop apps need to produce are invoices, delivery notes, certificates etc. I currently generate the SSRS reports entirely locally on the client machine (no server required). Can Power BI be embedded in desktop apps like this? What’s the recommended way of displaying Power BI reports in a .NET core WinForms project for example? Displaying them actually isn’t critical for me, if it’s possible to headlessly export the results locally to a PDF that would work too.

        • Jeremy LiknessMicrosoft employee 0

          I’ll have to look into the headless option. For embedding, the usual practice is via a WebView control. Here’s the document for PowerBI embedding.

          • Jason Brower 0

            Hello Jeremy, I was here for other purposes but stumbled upon the OP question so I thought I would post a related one. What is the recommended way of generating reports for a WPF application running against .Net5.0?

            In the current port of my software, I am trying to do everything in my power to avoid using third party controls; in part because I don’t want them to prevent me from stepping along side the past paced .Net pre releases.

            In prior versions of a large app that I am porting, I used RDLC to layout my reports and the LocalReport class to render the layout using data from view models. It worked great because I could pump out various formats including PDF and Excel. I never actually used the ReportViewer control itself, just the LocalReport feature and its dependency classes. I used a regular WPF DocumentViewer to show the PDF document.

            Concerned that this gap would arrive someday I mitigated this risk with a sprint that I did a while back. I used a DataTable that I converted to XPS and then I took that XPS and converted it to PDF using a customized branch of PdfSharp that I created. That PDF is then shown in the DocumentViewer as was the prior method. It worked well but I keep thinking there has to be a better way to support reporting in a XAML based Net5.0 application.

            If the above risk mitigation plan is put into play I will need to add support for pagination before the docs are converted to PDF and I will need to manually convert all of those RDLC report files into a XAML representation.

            I love coding but if you can save me lines of code without adding a third party dependency, I will virtually hug you (while wearing a COVID-19 approved facemask of course). This app is a point-of-sale application running on a touch terminal against SQL Express and a remote service. The local SQL db is to support offline use. Keeping deployment costs down is always a priority of my customers so I also need to avoid in additive paid versions of SQL Server. -Cheers, Jason

      • Heinrich Moser 0

        Hi Jeremy!

        Thanks for your open words. Obviously, this is not the answer we all were hoping for, but at least we know where we stand. At least for my company, embedding a third-party online service such as Power BI for PDF report generation is not an option.

        Goodbye RDLC! It’s been a good time, and we’ll miss you. Fortunately, there’s no lack for third-party reporting solutions for .NET Core.

        Best regards
        Heinzi

        • Mil Yan 0

          Yea, I don’t think they understand that. Its all about upselling Azure with them now. If you have built a business solution which cannot be ported to some form of cloud subscription with them, you might as well be leprous.

          • Heinrich Moser 0

            To be fair, you get what you pay for: Microsoft provided the LocalReport rendering engine for free, including royalty-free redistribution. That was a very nice thing to do, I am thankful for that, and they have every right to discontinue that product if it does not generate revenue.

  • Jason Brower 0

    Updated
    I just updated 150 csproj from preview 5 to preview 6; this follows a Visual Studio pre-release update as well as a Windows 10 update. The only conflict that I have right now is that it appears the WinRT team still needs to update the Microsoft.Windows.SDK.NET to be compatible with Preview 6 because using the following package with Preview 6 throws the following runtime exception.

    <PackageReference Include="Microsoft.Windows.SDK.NET" Version="10.0.18362.3-preview" />

    System.MissingMethodException: Method not found: 'Void System.Runtime.InteropServices.ComWrappers.RegisterAsGlobalInstance()'.
       at WinRT.ComWrappersSupport.get_ComWrappers()
       at WinRT.ComWrappersSupport.CreateRcwForComObject(IntPtr ptr)
       at WinRT.MarshalInspectable.FromAbi(IntPtr ptr)
       at ABI.Windows.Devices.Enumeration.DeviceWatcher.FromAbi(IntPtr thisPtr)
       at ABI.Windows.Devices.Enumeration.IDeviceInformationStatics.CreateWatcher(String aqsFilter)
       at Windows.Devices.Enumeration.DeviceInformation.CreateWatcher(String aqsFilter)
    

    I will have to go back to the gitHub post where I reported this 3 weeks ago to make sure the team knows it is blocking others who want to move onto the preview 6 build.

    I do love the pace your team is moving at, its a great time to be a .Net developer.

    Edit 1: I logged this WinRT repo issue moments ago.

    Edit 2 : It appears that there is also a conflict with System.Reactive that I thought would be good for any readers to know about. It seems that it is dependent on WinRT too. I logged this issue over in the Reactive repository.

  • Mike-E 0

    Nice work out there, team!

  • Wig Shire 0

    Does this work with WinUI preview 1?

  • Anthony Meehan 0

    Time to add ARM64 for MacOS? 🙂

  • James Wil 0

    still waiting for native static AOT compilation..

    why you so hesitant on talking about it, it’s almost like you despise this feature many are waiting for

    we need more transparency, it was announced last year, and since then, radio silence

    • Max Mustermueller 0

      Also still waiting. But Lander already said they will tell more about it in Preview 7 and this is only about Preview 6. Finger cross it will work with WPF applications too….

  • Colin Anderson 0

    We’ve updated our .NET 5 – Supported OS versions page to capture our latest plans for platform support for .NET 5.0. Please tell us what you think. What are we missing?

    Still missing Linux x86 🙁

    Linux x86 is still really important because of the lower memory usage – even Microsoft uses 32-bit by default in their Windows-based Azure App Services. There have been popular issues open about this in GitHub for years, and I’d really love to see official support for Linux x86 coming from the .NET team.

  • Rojan Gh. 0

    How is the Apple’s decision of migrating from Intel to Apple’s own chips going to affect the .Net?

  • blue yang 0

    Will coreclr add hybrid mode that already run in mono, allow coreclr interpreter, jit, aot mixed run at the same time?

Feedback usabilla icon