Announcing .NET Core 3.1 Preview 1

Avatar

Richard

Today, we’re announcing .NET Core 3.1 Preview 1. .NET Core 3.1 will be a small release focused on key improvements in Blazor and Windows desktop, the two big additions in .NET Core 3.0. It will be a long term support (LTS) release with an expected final ship date of December 2019.

You can download .NET Core 3.1 Preview 1 on Windows, macOS, and Linux.

ASP.NET Core and EF Core are also releasing updates today.

Visual Studio 16.4 Preview 2 and is also releasing today. It is a recommended update to use .NET Core 3.1 Preview 1. Visual Studio 16.4 includes .NET Core 3.1, so just updating Visual Studio will give you both releases.

Details:

Known Issue: The Visual Studio 16.4 installer may uninstall the .NET Core 3.0 Runtime when it installs .NET Core 3.1. We recommend you re-in-install or repair the .NET Core 3.0 SDK in that case.

Improvements

There are several targeted improvements planned for .NET Core 3.1. The following improvements are not available yet, but are expected in later previews.

In .NET Core 3.0, the .NET Core Desktop Runtime Installer (includes WPF and Windows Forms) does not install the .NET Core Runtime (includes CoreFX and CoreCLR) for you. We will be changing that, so that the Desktop Runtime installer is self-sufficient. The Runtime and Hosting Bundle, for server scenarios, already works this way.

C++/CLI was a promised component of the .NET Core 3.0 release. It was delivered, given that it is a required dependency of WPF, but a developer experience in Visual Studio and the SDK was missing. We will be delivering that experience with .NET Core 3.1 and Visual Studio 16.4. C++/CLI is only supported on Windows.

macOS 10.15 Catalina includes a new security requirement, that applications must be notarized. We will be satisfying these requirements for the .NET Core SDK, for .NET Core 3.1 and all other supported .NET Core releases. If you are using .NET Core to deliver macOS applications, we would appreciate working with you on notarization requirements.

Closing

The primary goal of .NET Core 3.1 is to polish the features and scenarios we delivered in .NET Core 3.0. .NET Core 3.1 will be a long term support (LTS) release, supported for at least 3 years.

Please install and test .NET Core 3.1 Preview 1 and give us feedback. It is not yet supported or recommended for use in production.

If you missed it, check out the .NET Core 3.0 announcement from last month.

Avatar
Richard Lander

Program Manager, .NET Team

Follow Richard   

39 comments

    • Avatar
      Sam Spencer

      Totally understood. The single file support in 3.0 was designed to solve deployment complications, and so bundled everything into the executable. The PublishTrimmed option looks to see what assemblies are used or not, and then excludes them. It doesn’t go to the next level which is to see which types & methods are used within the assembly and only including those.
      This is a problem we are looking at improving in v5. The problem is knowing exactly what is and isn’t used, especially when dynamism come in, such as dependency injection, late data binding or other uses of reflection. This was the same problem faced with .NET Native. If you get it wrong you end up with an app that can fail unpredictably.
      So we are taking to heart lessons learned in that project, with the goal to give a predictable outcome – we will only trim what we can validate will not cause problems, and will fail the build if that can’t be guaranteed.

      • Avatar
        Eaton Zveare

        Hi Sam, thanks for the response. I hope you will also be able to exclude entire assemblies. If you create a DevExpress WinForms app, it will reference and publish only a few DevExpress DLLs. If you do the same with .NET Core, it bundles all of them. The vast majority of those DLLs aren’t needed at all. I’ve worked around this by dereferencing their NuGet package and just directly reference the DLLs I know I need. This is not ideal and hopefully by v5, things will be considerably better.😉

      • Jeff Johnson
        Jeff Johnson

        The [Preserve] attribute that Xamarin has is wonderful. Would be nice to have it in .NET standard 2.2. Maybe it’s already there and I missed it? Then we can simply mark things we know we are using with special reflection or dependency injection.

  • Avatar
    Nick K

    I still don’t understand how you can support .NET Core for only 3 years and call it “Long Term Support”. Suppose I create a desktop application. It takes on the order of 2-3 years to create a new version and have the end users accept it for use. Creating a new version, no matter how trivial the change (say, recompiling to support a newer version of the .NET Core framework), necessitates another really long and expensive review cycle. These end users will then use it for some number of years (decades?) to come. I am guaranteed to have every single one of my users use an “unsupported” version of the .NET Core runtime. What do I tell those users? Do I just stick with .NET 4?

    • Avatar
      JesperTreetop

      Completely agreed with this – Microsoft is essentially locking everyone into .NET Framework, if you want to ship something on a platform that you won’t get locked out of within a few years. Desktop software lives a lot longer, and having WPF and Windows Forms available is necessary but not sufficient.

    • Avatar
      Richard Lander

      We encourage you to move forward along the tip versions while you are developing your application. We’ve talked to many developers that have been successful doing that. If you need longer than three years of support, then maybe .NET Framework is a better choice, as you suggest. .NET Core is a faster moving project. It is delivering a lot of value, and part of that is achieved by not having to support so many different versions at once. For .NET Framework, we support every version from .NET Framework 4.5.2 and on. That doesn’t include .NET Framework 2.0, 3.0 and 3.5, which we also support. That’s a lot of versions. We believe that we’ve made a good value trade-off with .NET Core and many people like it because of that.

        • Avatar
          equasar

          Well, just update the version. IMHO, there won’t be any breaking changes, but if they do, they will be like very minor changes.

          • Avatar
            Jon

            By definition, major version number changes are guaranteed to include breaking changes.

            Realistically, people just have to move faster. Outside of .NET Framework this has been the trend for close to a decade. I work on decade-lifecycle enterprise apps myself, and I’ve spent the past several years trying to push the message, “suck it up and deal with it.”

            Staying on .NET Framework is not a solution, it’s a dead end.

          • Jeff Johnson
            Jeff Johnson

            From the web side, when going from 2 to 3, it took me a few weeks to fix all the things that didn’t compile or were broken because there were new/different ways of doing them. This was with a pretty small web api too, nothing remotely big.

          • Avatar
            Andrew Buchanan

            My past experience is that asp.net versions almost always include breaking changes. Framework updates generally haven’t badly broken things for me, but they can.

            If I target .net core 3.1, what’s the risk the app can’t be upgraded to .net 6.1 (or whatever the future version is called) without rewriting large portions of it?

            In a large 9 year old .net framework app I’ve worked on we’ve seen tech like aspx, mvc 2/3/4/5, wcf rest, wcf soap, etc all get left behind. On desktop .net, even though they’re essentially dead tech, they do continue to work. In .net core, as tech eventually dies, I’m less sure what compatibility looks like.

        • Avatar
          Richard Lander

          You would then need to upgrade to 5.0 or 6.0. We are very much wanting to enable people to upgrade and for that to be easy.

          • Avatar
            James Chaldecott

            And yet you continually point out that the reason for stopping development for .Net Framework is that having to worry so much about breaking compatibility is slowing development down (I’ve seen the word “albatross” used). By definition that means that we need to expect breaking changes between future .Net [Core] versions.

            You can’t have it both ways and say that .Net Core is freeing you (us?) from compatibility constraints, but it will somehow also be pain-free to upgrade between versions.

            I honestly think you’ve underestimated how much of the Microsoft value proposition is “stable, well documented stuff that will be supported for years”.

            I don’t want to be that guy that just complains. I dounderstand your POV, but I think there needs to at least be a detailed list of known breaking changes between major versions (and definitely between .Net 4.8 & 5.0).

          • Avatar
            Richard Lander

            Replying to @James Chaldecott — You raise a great point about the difference between .NET Core and .NET Framework compat. That’s an excellent point. The only model we have with .NET Framework is binary compat. With .NET Core, we have the option of making breaking changes that require source changes. Even if they only take a developer 5mins to port an app, this is an enormous different compared to .NET Framework.

          • Avatar
            Jamshed Damkewala

            Replying to @James Chaldecott – we do document known breaking changes between versions, for e.g. this is the list of known breaking changes between Core 2.2 -> 3.0.

            If we receive a report of a breaking change not previously known to us, we’d first consider whether we can treat it as a bug and fix it in a subsequent release or update. If that’s not possible for some reason then we would update our breaking change docs to include the new item.

        • Nick Robitsch
          Nick Robitsch

          We have been using Core in many of our production servers since V1. Talk about a headache. There were some massive breaking changes between 1 and 2. This is not as much the case with 2 to 3. If you are not in a monolith architecture this really shouldn’t be much of an issue. As Core matures and becomes more established, I think this will become a non-issue as it did with framework.

          I found it extremely simple to migrate from Core 2.1 to 3.0.

          Framework to Core however…. thats another story.

    • Trust Mutemasango
      Trust Mutemasango

      We are in the same boat I decided to move everything to .Net 4.8 I will only use .Net Core for web related stuff.

    • Avatar
      Nathaniel Armer

      You might want to revisit your development/maintenance model.

      Spending 3 (!!!) years developing an application, but being unable to update your framework during that time seems odd. To then support it for decades, without maintenance (e.g. updating frameworks)… seems designed to fail?

      Keep in mind Ubuntu LTS is only 3 years for desktop, and Windows 10 versions are only 30 months (for enterprise versions on the September update). As such I wonder how you’ll even maintain OS support, let alone framework.

      • Avatar
        Nick K

        You need to look into how enterprise and engineering applications work. Suppose you make an application that calculates how you can build a skyscraper, you populate it with all the data, you do extensive validation of the application and the model, and you use the result to get your city permits, and to actually build the skyscraper. At this point, your application and your model are frozen. Now 10 years down the road you want to re-run the application to see if you can replace all the windows without breaking the structural integrity. Oh, too bad, your application needs .NET framework 3.1, we now only support .NET framework 14. So you can either spend your time validating a new version of the application, mucking with your model, trying to figure out all the “tricks” to upgrade it, or … I don’t know, run the version and the model used as the design basis. What’s more appealing to you as the person who has to pay for these replacement windows? Let’s make this scenario even more fun: the software developer went out of business and didn’t release any new versions. The source code is effectively gone. Now what?

  • Andrew Osman
    Andrew Osman

    Hi, you mention that C++/CLI was delivered as part of .Net Core 3.0. I’m glad to hear that. Clearly you have a way to use it using existing tools since, as you say, it was necessary for WPF support. How then do I use it using existing tools?

  • Avatar
    Ismail Demir

    Request: I still waiting for a roadmap of VB.Net!

    Question: Compared to applications that written in c++/c# how fast will be vb.net winform applications be opened?

    Is there any internal benchmarks?

    Thank you

  • Avatar
    Robert Sundström

    Regarding C++/CLI and the interop story… With the announcement of .NET 5, Microsoft promised interop with other languages (Java and Python etc). I assume that the the Xlang project will be the basis for that. It is already used by the C++/WinRT projection.

    The project is essentially fulfilling what .NET/CLI was supposed to be – a successor to COM. Cross-platform, of course.

    It is still early but I will follow the project closely!

    https://github.com/microsoft/xlang

  • Avatar
    Jason Brower

    I really appreciate all that Microsoft is doing for the .Net Framework. Almost daily I check to see if there is a new Visual Studio preview release out and when I see that it needs to update I am like a child on Christmas waiting to see what comes with the previews of the framework.

    I feel like a brave soul jumping into the latest and greatest each time because my long term project is now up to over 130 csproj all targeting .net standard, netcore including netcore WPF.

    My largest going concern is and has always been, wondering where / when / how Microsoft will address user interface library improvements regarding XAML/WPF. I have been programming with WPF since 2008 or so. It has been a dream come true when it comes to decoupling the UI, but as great as that is, the rendering speed causes end users to ask why it is slow compared to Windows Forms. I explain the many reasons why I will not return to Windows Forms, yet can’t help but grow frustrated waiting for improvements.

    Unlike others, I moved everything into dotnetcore and have no problem with the 3 year support cycle as I also rev my software quickly. I appreciate the amazing things that you are all doing, keep up the good work.

    • Avatar
      Jon

      I sympathize and this is nothing more than a passing comment from the peanut gallery, but you should try being stuck maintaining web-based apps. WPF is a dream compared to that god-awful development model. (Once, long ago, I was a native desktop app dev…)

  • Avatar
    Nilesh Pagare

    Hi Richard,

    *Updating VS to 2019.4 / .5 didn’t upgrade the .net Core from 3.0 to 3.1 latest preview as a part of the install

    *I enabled the option in the VS Studio to selecting preview sdk but that didn’t show up those packages in the NuGet package manager (solution / project) when this option is selected

    *Are dotnet ef tools updated (functionally and/or version numbers) in 3.1 preview 1 ? If so, how do we upgrade those tools ? Neither the link https://docs.microsoft.com/en-us/dotnet/core/tools/troubleshoot-usage-issues nor the powershell commandlet Update-Package Microsoft.EntityFrameworkCore.Tools provides any information on this.

    *Any plans for bringing back the model first approach including model designer in 3.1 ?

    Thank you

  • Avatar
    Nejc Brelih-Wasowski

    Does anyone know if or how is it possible to install the preview version alongside the stable one on linux (Ubuntu)? I installed the preview version into a local folder and did a path and DOTNET_ROOT export but I am still only seeing the stable one. Even when 3.0 was in preview I had to remove 2.x versions for the preview to work.

  • Thomas De Wulf
    Thomas De Wulf

    Well a rare UWP developer in the house here…. 🙂 When will this be supported so I can upgrade my Nuget packages to .NET standard 2.1 in my UWP apps.

  • Avatar
    piotr olczyk

    I would like to ask about suport to USB?
    Is the assembly Windows.Devices.HumanInterfaceDevice, which is a part of Windows UWP Namespaces is supported by NET.Core 3.0?

Leave a comment