Announcing .NET Core 3.1



Announcing .NET Core 3.1

We’re excited to announce the release of .NET Core 3.1. It’s really just a small set of fixes and refinements over .NET Core 3.0, which we released just over two months ago. The most important feature is that .NET Core 3.1 is an long-term supported (LTS) release and will be supported for three years. As we’ve done in the past, we wanted to take our time before releasing the next LTS release. The extra two months (after .NET Core 3.0) allowed us to select and implement the right set of improvements over what was already a very stable base. .NET Core 3.1 is now ready to be used wherever your imagination or business need takes it.

You can download .NET Core 3.1, for Windows, macOS, and Linux:

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

Visual Studio 2019 16.4 was also released today and includes .NET Core 3.1. It is a required update to use .NET Core 3.1 with Visual Studio. For Visual Studio 2019 users, we recommend simply updating Visual Studio to 16.4 and instead of separately downloading .NET Core 3.1.

Visual Studio for Mac also supports and includes .NET Core 3.1, in the Visual Studio for Mac 8.4 Preview channel. You will need to opt into the Preview channel to use .NET Core 3.1.

Release notes:

The changes in .NET Core 3.1 were primarily focussed on Blazor and Windows Desktop, the two new and large additions in .NET Core 3.0. This includes support for C++/CLI, which has been a regular request for developers targeting Windows.

Before we take a look at what’s new in .NET Core 3.1, let’s take a quick look at the key improvements in .NET Core 3.0, which is the bulk of what’s important to consider for .NET Core 3.1.

Recap of .NET Core 3.0 Improvements

The following key improvements were delivered in .NET Core 3.0. We’ve already heard from developers of big sites that it is working super well for them.

  • .NET Core 3.0 is already battle-tested by being hosted for months at and on Many other Microsoft teams will soon be deploying large workloads on .NET Core 3.1 in production.
  • Performance is greatly improved across many components and is described in detail at Performance Improvements in .NET Core 3.0 and Hardware Intrinsics in .NET Core.
  • C# 8 add async streams, range/index, more patterns, and nullable reference types. Nullable enables you to directly target the flaws in code that lead to NullReferenceException. The lowest layer of the framework libraries has been annotated, so that you know when to expect null.
  • F# 4.7 focuses on making some thing easier with implicit yield expressions and some syntax relaxations. It also includes support for LangVersion, and ships with nameof and opening of static classes in preview. The F# Core Library now also targets .NET Standard 2.0. You can read more at Announcing F# 4.7.
  • .NET Standard 2.1 increases the set of types you can use in code that can be used woth both .NET Core and Xamarin. .NET Standard 2.1 includes types since .NET Core 2.1.
  • Windows Desktop apps are now supported with .NET Core, for both Windows Forms and WPF (and open source). The WPF designer is part of Visual Studio 2019. The Windows Forms designer is in preview and available as a download.
  • .NET Core apps now have executables by default. In past releases, apps needed to be launched via the dotnet command, like dotnet myapp.dll. Apps can now be launched with an app-specific executable, like myapp or ./myapp, depending on the operating system.
  • High performance JSON APIs have been added, for reader/writer, object model and serialization scenarios. These APIs were built from scratch on top of Span<T> and use UTF8 under the covers instead of UTF16 (like string). These APIs minimize allocations, resulting in faster performance, and much less work for the garbage collector. See Try the new System.Text.Json APIs.
  • The garbage collector uses less memory by default, often a lot less. This improvement is very beneficial for scenarios where many applications are hosted on the same server. The garbage collector has also been updated to make better use of large numbers of cores, on machines with >64 cores. See Making CPU configuration better for GC on machines with > 64 CPUs.
  • .NET Core has been hardened for Docker to enable .NET applications to work predictably and efficiently in containers. The garbage collector and thread pool have been updated to work much better when a container has been configured for limited memory or CPU. .NET Core docker images are smaller, particularly the SDK image. See: Running with Server GC in a Small Container Scenario Part 0, Running with Server GC in a Small Container Scenario Part 1 – Hard Limit for the GC Heap and Using .NET and Docker Together – DockerCon 2019 Update.
  • Raspberry Pi and ARM chips are now supported to enable IoT development, including with the remote Visual Studio debugger. You can deploy apps that listen to sensors, and print messages or images on a display, all using the new GPIO APIs. ASP.NET can be used to expose data as an API or as a site that enables configuring an IoT device.

Platform support

.NET Core 3.1 is supported on the following operating systems:

  • Alpine: 3.10+
  • Debian: 9+
  • Ubuntu: 16.04+
  • Fedora: 29+
  • centOS: 7+
  • RHEL: 6+
  • openSUSE: 15+
  • SUSE Enterprise Linux (SLES): 12 SP2+
  • macOS: 10.13+
  • Windows Client: 7, 8.1, 10 (1607+)
  • Windows Server: 2012 R2+

Note: Windows Forms and WPF apps are only functional and supported on Windows.

Chip support follows:

  • x64 on Windows, macOS, and Linux
  • x86 on Windows
  • ARM32 on Windows and Linux
  • ARM64 on Linux (kernel 4.14+)

Note: Please ensure that .NET Core 3.1 ARM64 deployments use Linux kernel 4.14 version or later. For example, Ubuntu 18.04 satisfies this requirement, but 16.04 does not.

Windows Forms Controls Removal

The following Windows Forms controls have been removed from .NET Core 3.1:

  • DataGrid
  • ToolBar
  • ContextMenu
  • Menu
  • MainMenu
  • MenuItem

These controls were replaced with more powerful controls in .NET Framework 2.0, back in 2005. They have not been available by default in the Visual Studio Designer Toolbox for many years. As a result, we decided to remove these controls and focus only on the new ones.

The following replacements are recommended:

Old Control (API)Recommended ReplacementOther associated APIs removed
DataGridDataGridViewDataGridCell, DataGridRow, DataGridTableCollection, DataGridColumnCollection, DataGridTableStyle, DataGridColumnStyle, DataGridLineStyle, DataGridParentRowsLabel, DataGridParentRowsLabelStyle, DataGridBoolColumn, DataGridTextBox, GridColumnStylesCollection, GridTableStylesCollection, HitTestType
ToolBarButtonToolStripButtonToolBarButtonClickEventArgs, ToolBarButtonClickEventHandler, ToolBarButtonStyle, ToolBarTextAlign
MenuToolStripDropDown, ToolstripDropDownMenuMenuItemCollection

Yes, this is an unfortunate breaking change. You will see build breaks if you are using the controls we removed in your applications. Also, if you open .NET Core 3.0 applications in the latest versions of the .NET Core Windows Forms designer, you will see errors if you are using these controls.

We recommend you update your applications to .NET Core 3.1 and move to the alternative controls. Replacing the controls is a straight-forward process, essentially “find and replace”.

First, we should have made these changes before we released .NET Core 3.0, and we appologize for that. We try to avoid late changes, and even more for breaking changes, and it pains us to make this one.

As we got further into the Windows Forms designer project, we realized that these controls were not aligned with creating modern applications and should never have been part of the .NET Core port of Windows Forms. We also saw that they would require more time from us to support than made sense.

Our goal is to continue to improve Windows Forms for high DPI, accessibility, and reliability, and this late change was required to enable us to focus on delivering that.


We added support for creating C++/CLI (AKA “managed C++”) components that can be used with .NET Core 3.0+, in Visual Studio 2019 16.4. You need to install the “Desktop development with C++” workload and the “C++/CLI support” component in order to use C++/CLI.

This component adds a couple templates that you can use:

  • CLR Class Library (.NET Core)
  • CLR Empty Project (.NET Core)

If you cannot find them, just search for them in the New Project dialog.

C++/CLI is only enabled on Windows. You cannot use C++/CLI components targeted for .NET Framework with .NET Core or vice versa.


We recommend moving to .NET Core 3.1 as soon as you can. It is a great release (largely due to 3.0) that brings improvements to so many aspects of .NET Core. It is also a long term support (LTS) release, and will be supported for three years.

Life cycle update:

  • .NET Core 3.0 will reach end-of-life three months from today, on March 3, 2020.
  • .NET Core 2.2 will each end of life on December 23rd.
  • .NET Core 2.1 will be supported until August 2021 (it is also an LTS release).

The following .NET Core posts are recommended reading to learn more about what you get with .NET Core 3.1 and other projects we’ve been working on.






Leave a comment

  • Avatar
    Max Mustermueller

    The added messagebox if .NET Core runtime is missing on non self-containd applications is my personal highlight of the .NET Core 3.1 release. I’ve been waiting for this since .NET Core 3.0 before I ship out my ported applications. Thank you so much for adding this!

      • Avatar
        Richard LanderMicrosoft logo

        The 3.0 and 3.1 runtimes are now available in most regions. The SDK is not and is still coming. I don’t have a date on that. If you rely on Kudu deployment, then you need the SDK. If you use Azure DevOps or other approaches to deploy your application, then you only need the runtime and are good-to-go now.

        • Avatar
          Darren Ford

          My app service was apparently updated with core 3.1 and now I am running into a CORS error this is a bit odd. To confirm, I test locally with core 3.0 one last time before updating to latest VS 2019 that installs 3.1. After updating locally, I now get the error locally. The error is:

          Endpoint [Redacted] contains CORS metadata, but a middleware was not found that supports CORS.
          Configure your application startup by adding app.UseCors() inside the call to Configure(..) in the application startup code. The call to app.UseAuthorization() must appear between app.UseRouting() and app.UseEndpoints(…)

          Everything was working but now this. Anyone come across this yet?

          • Avatar
            Darren Ford

            For anyone who runs across this. I moved app.UseCors AFTER app.UseRouting and the issue in .net core 3.1 went away. Something changed related to this in 3.1.

  • Avatar
    Dave Bacher

    I know a lot of times I’m negative – but all these changes are welcome. However:
    .NET Core apps now have executables by default. In past releases, apps needed to be launched via the dotnet command, like dotnet myapp.dll. Apps can now be launched with an app-specific executable, like myapp or ./myapp, depending on the operating system.

    ^ This is fantastic. Mind you, I’m in favor of all the other changes this time around (that’s not always the case), but this one specifically is huge.

  • Avatar
    Les Thomas (TheDestinyGroup)


    I just installed the .Net Core 3.1 Hosting bundle and at one point during the installation I noticed it said it something like installing .Net Core 3.1.0 Preview 3.

    After the installation completed I went to Add/Remove programs and noticed that it had installed “Microsoft .Net Core 3.1.0 – Windows Server Hosting” along with “Microsoft .Net Core Runtime – 3.1.0 Preview 3 (x64)” and “Microsoft .Net Core Runtime – 3.1.0 Preview 3 (x86)”.

    Why is the .Net Core 3.1 Hosting bundle installing the .Net Core 3.1 runtimes which are labelled as “3.1.0 Preview 3” rather than the expected “3.1.0”?

    Even if the Runtime didn’t change between Preview 3 release and general availability release both the name shown in the installers UI and name shown in Add/Remove programs should have been updated to reflect the products correct naming for the general availability release as corporate customers don’t expect to see products labelled with alpha, beta or release preview naming installed on their production servers.


    PS: It appears the downloads for the x86 and x64 .Net 3 Core Runtimes are also named in the installers UI and in Add/Remove programs as .Net Core 3.1 Preview 3.

  • Avatar
    Jens Hofmann

    Hey Richard,

    I search the last couple of month is someone has the same problems like us but I dit not find anything so I try asking here.
    We do have a self-contained .net core 3 app called fastunpack/fastpack.

    This app suddenly does no longer work and quits starting with the following error:

    An assembly specified in the application dependencies manifest (FastUnpack.deps.json) was not found:
    package: '', version: '3.0.0'
    path: 'System.Collections.Specialized.dll'

    Deleting the cache folder and starting the app again fixes this error.
    As we can track it down, this problem starts arising when a windows update happened.

    Are we the only ones having that problem?
    This problem is very frustrating for us because the tool is a tool used for build- and testautomation which currenty suddenly breaks.


      • Avatar
        Stephen White

        It works but the Microsoft Hosted Windows Agents appear to not be up to date with the latest version of VS. If I try to do a release build with 3.1 and the desktop bridge, the build always fails with this error, which looks like the kind I see if publishing profiles are wrong:

        C:\hostedtoolcache\windows\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(234,5): Error NETSDK1005: Assets file ‘d:\a\1\s\Application\YourProject\obj\project.assets.json’ doesn’t have a target for ‘.NETCoreApp,Version=v3.0’. Ensure that restore has run and that you have included ‘netcoreapp3.0’ in the TargetFrameworks for your project.
        Process ‘msbuild.exe’ exited with code ‘1’.

        Unless someone here has a work around to get it to work in Azure Devops, I’ll probably have to use my own work around for now. 🙁

        • Avatar
          Richard LanderMicrosoft logo

          Understood. This is less about .NET Core 3.1 and more about Visual Studio 2019 16.4. You’ll have to wait until 16.4 is made available. I don’t know what the pattern is for deploying new VS versions in DevOps.

  • 王宏亮

    Windows controls removal is really a bad idea,why not marking those controls obsolete and adding new ones to achieve maximum
    backward compatibility? Many applications depend on the third libraries, and those libraries depend on removed controls,thus upgrades
    are greatly hindered, even impossible.

        • Olia Gavrysh
          Olia GavryshMicrosoft logo

          Unfortunately we cannot continue to innovate in the .NET Core WinForms with these controls, they would challenge such features as high DPI, accessibility, and reliability. The controls were considered obsolete for 14 years already. We left them for compatibility only, keeping in mind that eventually we will move to the new controls completely.

          We saw many people have upgraded and been happy with the new alternatives. So maybe give them a chance? 🙂 But if you want to keep using the old controls, you can totally stay on .NET Framework, which is not going anywhere and will be supported. .NET Core is a new, fast developing platform that enables all the latest improvements and innovations, and in order for us to keep it that way we had to clean up the code from some obsolete parts. Sorry that it impacted you.

    • Avatar
      Richard LanderMicrosoft logo

      I updated the requirement to just “2012 R2”. Sorry about that. The main take-away is that we don’t support Windows Server 2008 anymore. You need to use .NET Core 2.1 if you want support for Windows Server 2008.

  • Avatar
    Денис Перевозчиков

    When will it be available via apt on Ubuntu 18.04?

    sudo apt list dotnet-sdk*
    Listing… Done
    dotnet-sdk-2.1/bionic 2.1.802-1 amd64
    dotnet-sdk-2.1.105/bionic 2.1.105-1 amd64
    dotnet-sdk-2.1.200/bionic 2.1.200-1 amd64
    dotnet-sdk-2.1.201/bionic 2.1.201-1 amd64
    dotnet-sdk-2.1.202/bionic 2.1.202-1 amd64
    dotnet-sdk-2.1.300-preview2-008533/bionic 2.1.300-preview2-008533-1 amd64
    dotnet-sdk-2.1.300-rc1-008673/bionic 2.1.300-rc1-008673-1 amd64
    dotnet-sdk-2.2/bionic,now 2.2.402-1 amd64 [installed]
    dotnet-sdk-3.0/bionic,now 3.0.101-1 amd64 [installed]

  • Avatar
    Oliver Weichhold

    As someone working on Net Core projects that often have to invoke C/C++ libraries for performance reasons on Windows and Linux, it would be fantastic if C++/CLI would be supported cross-platform. PInvoke is a workaround but C++/CLI is so much nicer.

    • Avatar
      Jon Miller

      I take back what I said about the latest EF Core not working with it. I see that support for it on .NET Framework has been reintroduced. Thank you! However, I am still unthankful for ASP.NET Web Forms not being moved forward onto .NET Core. Scott Guthrie designed it right back in 2000. It works and it has been a productive way to develop applications ever since then.

      • Avatar
        Richard LanderMicrosoft logo

        And it will keep on working for you, for a long-time, on .NET Framework.

        We are never going to enable web forms on .NET Core. Blazor is our new story for a similar kind of experience and people are super happy with it. I understand why you are unhappy. However, we’ve got a new solution that is aligned with modern patterns that a high percentage of .NET users are happy with. In the aggregate, that’s a winning proposition.

        • Avatar
          Jon Miller

          Except that new language features aren’t going into .NET Framework. It will be years before Blazor has matured. Why don’t you develop a robust set of UI controls for it? You would have me sold if you did that. You won’t do it though.

          • Avatar

            Realistically Web Forms was dead almost a decade ago when they renamed ASP.NET to ASP.NET MVC, and I say good riddance. If you review the history of Web Forms, it saw almost no changes after MVC showed up. There’s nothing wrong with MVVM per se, but Web Forms allows — and almost encourages — a lot of truly awful development practices (and if you’ve worked with lowest-bidder contractor code, you’ll have seen the worst of the worst). I’ve been doing large enterprise-style server-side Blazor POCs and it’s mostly a joy to work with. My only complaint is that they haven’t put a near-term end-of-life date on the .NET Framework itself.

          • Avatar
            Jon Miller

            Does Blazor have an editable combobox? Does it have a grid control with built-in filtering, sorting, grouping, and inline editing? Let me know when it does and maybe I will be the biggest booster of it. MVC lacked from day one due to the simple fact that it lacked the concept of UI controls. It depends on what kind of app you are developing, if you are developing something like an UI, no, you don’t need robust UI controls, at least not for the read-only parts of it. However, that doesn’t describe the requirements for all applications that are out there. I strongly disagree with those who think you need to program web apps at the bare metal. You should write apps at the proper level of abstraction. Web Forms does that and always has. MVC never did. I am an application developer. I want to focus on the business logic that I am tasked with developing, not developing my own UI controls. I will be extremely surprised if Microsoft includes robust UI controls in Blazor. If they do, they will have a winner. One should not have to rely on third party UI controls at this late date. The ease of application development should be getting better. Maybe it will eventually with Blazor, but, it has been an abject failure for about the last 10 years. Luckily, I was able to avoid 99% of the JavaScript and web API hell that the experts are inflicting on everyone, by simply staying the course and not being a lemming following bad ideas.

  • Athanasios Ioannidis
    Athanasios Ioannidis

    Just updated to VS 2019 16.4. My core 3.0 framework depended app now fails with a 500.30 ACNM error. I installed, uninstalled and reinstalled 3.1 hosting bundle, but nothing works. I updated the projects and all the nuget packages to 3.1, and still the process cannot start. Debugging with F5 actually enters the process and fails a few moments later. The only message I could see was a null reference exception deep within a system assembly.

    On the other side, a brand new 3.1 (or 3.0) web site starts normally.

    Is this connected with the preview3 problem?

    • Avatar
      Steven He

      VB.NET console and test projects are completely supported, however, due to lacking of VB desktop runtime on .NET Core (which is still under development), there’s no support to winforms and WPF for VB.NET currently.

  • Kenneth Carter
    Kenneth Carter

    updating visual studio 2019 installed .net core 3.1 but wiped clean and corrupted the 2.1, 2.2 .net core installs. now the .net core 2.2 app I was working on will not run unit tests because the 2.2 sdk is no longer there.

  • Avatar
    Karl X

    Following the instructions here: I still only see preview3.

    apt-cache show dotnet-runtime-3.1
    Package: dotnet-runtime-3.1
    Priority: standard
    Section: libs
    Installed-Size: 71059
    Maintainer: .NET Core Team
    Architecture: amd64
    Version: 3.1.0-1
    Depends: dotnet-hostfxr-3.1 (>= 3.1.0), dotnet-runtime-deps-3.1 (>= 3.1.0)
    Filename: pool/main/d/dotnet-runtime-3.1/dotnet-runtime-3.1.0-x64.deb
    Size: 21764038
    MD5sum: d224731e908efaf2af884c49002c8649
    SHA1: e0ae40d1d433033adaf666b8cc5a40ed8101903b
    SHA256: 4df4f5a8eeb62f211f323912d1af87ddb4c560f85f991c2db3cddec61de7a6c5
    SHA512: 7b32079d8b53a1d104ea36e90164b684a6e888228fc1c0db29f133d4b0bc1fb2c2a937cd9f73ffbfe575566758ea3306abcb69561a54abbcf70186a21159bd2a
    Description: Microsoft .NET Core Runtime – 3.1.0 Preview 3 Microsoft.NETCore.App 3.1.0
    .NET Core is a development platform that you can use to build command-line applications, microservices and modern websites. It is open source, cross-platform and is supported by Microsoft. We hope you enjoy using it! If you do, please consider joining the active community of developers that are contributing to the project on GitHub ( We happily accept issues and PRs.
    Description-md5: b7dfb35a3c6552225d0f65dedcbbfbbf

  • Avatar
    Dimitri Samorukov

    i have problems with compiling of WPF applications for windows desktop, with then new version of Visual Studio ( Professional 2019
    Version 16.4.0 ) After update and creating a new WPF-Project, i get following error:

    1>C:\Program Files (x86)\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\Microsoft.WinFX.targets(225,9): error MSB4062: The Microsoft.Build.Tasks.Windows.MarkupCompilePass1 task could not be loaded from the C:\Program Files %28×86%29\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\tools\net472\PresentationBuildTasks.dll assembly. The file or assembly “file:///C:\Program Files %28×86%29\dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk.WindowsDesktop\tools\net472\PresentationBuildTasks.dll” or a dependency on it was not found. The system cannot find the specified file. Make sure that the declaration is correct, the assembly and all associated dependencies are available, and the task contains a public class that implements Microsoft.Build.Framework.ITask.

    .net SDK 3.1.100 is installed and is available under the given path, the operation system and visual studio are using the german language.
    What ist the problem here ?

  • Raghavendra Rao Itikarlapalli
    Raghavendra Rao Itikarlapalli

    Earlier we’ve used .NET Core 2.2.105 to build our applications using the below command.
    dotnet publish –configuration Release –force –output publish ABC.sln
    This ultimately created a publish folder and we used to copy contents from that folder. But recently we’ve upgraded it to .NET Core 3.1.100 and it failed to generate this publish folder.

    Is there any additional parameter that we need to provide in order to create a publish folder?

  • Avatar
    Matthew Whited

    Any chance the 4.x version of the EventHub library for azure will be fixed any time soon… it would be nice to actually have the ability to use the latest client with Azure Functions v3. As it is the EventHub trigger throws an error if you try to use the latest public bits saying it can’t find a constructor for one of the exceptions.

  • Victor Tseng
    Victor Tseng

    The comments are quite lengthy so sorry if someone else already commented something similar:

    In the Platform Support section, the CentOS is not listed while in the msdn document it is:

    This should be just a typo but scared me a little bit as we are planning to use CentOS in production to run .NET Core applications in container.