.NET Core February 2020 Updates – 2.1.16, 3.0.3, and 3.1.2

Rahul Bhandari (MSFT)

February 18th, 202014 0

Today, we are releasing the .NET Core February 2020 Update. These updates only contain non-security fixes. See the individual release notes for details on updated packages.

NOTE: If you are a Visual Studio user, there are MSBuild version requirements so use only the .NET Core SDK supported for each Visual Studio version. Information needed to make this choice will be seen on the download page. If you use other development environments, we recommend using the latest SDK release.

Getting the Update

The latest .NET Core updates are available on the .NET Core download page. This update will be included in a future update of Visual Studio.

See the .NET Core release notes ( 2.1.16 | 3.0.3 | 3.1.2 ) for details on the release, including issues fixed and affected packages.

Docker Images

.NET Docker images have been updated for today’s release. The following repos have been updated.

Note: You must pull updated .NET Core container images to get this update, with either docker pull or docker build –pull.

Rahul Bhandari (MSFT) Program Manager, .NET

Read next

ASP.NET Core Apps Observability
Based on interactions with customers using .NET Core in different environments, this article explores options for adding observability to .NET Core apps. Looking specifically into OpenTelemetry and Application Insights SDKs to add observability to a sample distributed application.
Francisco Beltrao
February 26, 2020
5 comments

14 comments

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

  • Rob Arthur 0

    We’re seeing issues installing 2.1.16 on ubuntu 16.04. Were there some bad dependencies published?

    ubuntu@host:~$ sudo apt-get update && sudo apt-get install -y dotnet-sdk-2.1
Hit:1 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial InRelease
Hit:2 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-updates InRelease                                              
Get:3 http://us-east-1.ec2.archive.ubuntu.com/ubuntu xenial-backports InRelease [107 kB]                                                         
Ign:4 http://us-east-1.ec2.archive.ubuntu.com/ubuntu precise InRelease                                                                                                                
Get:5 http://security.ubuntu.com/ubuntu xenial-security InRelease [109 kB]                                                                           
Ign:6 http://archive.ubuntu.com/ubuntu trusty InRelease                                                                                              
Hit:7 https://packages.microsoft.com/ubuntu/16.04/prod xenial InRelease                                                                              
Hit:8 http://download.mono-project.com/repo/debian wheezy InRelease                                                                                  
Hit:9 http://download.mono-project.com/repo/debian wheezy-apache24-compat InRelease                                                                  
Hit:10 https://deb.nodesource.com/node_8.x xenial InRelease                                                                                          
Hit:11 http://repo.saltstack.com/apt/ubuntu/16.04/amd64/2019.2 xenial InRelease                                                                      
Hit:12 http://us-east-1.ec2.archive.ubuntu.com/ubuntu precise Release                                                                                
Hit:13 http://archive.ubuntu.com/ubuntu trusty Release                                                   
Hit:15 https://packagecloud.io/github/git-lfs/ubuntu xenial InRelease              
Fetched 216 kB in 0s (259 kB/s)
Reading package lists... Done
W: http://us-east-1.ec2.archive.ubuntu.com/ubuntu/dists/precise/Release.gpg: Signature by key 630239CC130E1A7FD81A27B140976EAF437D05B5 uses weak digest algorithm (SHA1)
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 dotnet-sdk-2.1 : Depends: dotnet-runtime-2.1 (>= 2.1.16) but it is not going to be installed
                  Depends: aspnetcore-runtime-2.1 (>= 2.1.16) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
  • Ion Sorin Torjo 0

    I don’t understand – why did .netcore 2.2 reach EOL on 2019.12.2023, and .netcore 2.1 will reach EOL on 2021.08.21?

    Basically, I would really not care if I could use .netcore 3.1 on UWP – but can I?

    later edit: apparently UWP still relies on .netcore runtime 2.2 – so how come this reached EOL 2 months ago?

    • Codest 0

      .NET Core 2.1 is a long-term support (LTS) release. This means that it is supported for three years.

      • cheong00 0

        It’s kind of puzzling why Microsoft don’t make .NET Core 2.2 LTS instead.

        I thought it’s common practice to make the final minor version release of a major version LTS, so people who prefer to stay in that major version won’t need to choose between “losing improvements from the LTS to the current version they’re using” or “missing security patch for vulnerability discovered after your minor version goes EOL”.

  • Rajasekar Shanmugam 0

    Our build systems are down due to an update of Microsoft.AspNetCore.Identity.EntityFrameworkCore to version 3.1.2, but dependent package Microsoft.EntityFrameworkCore.Relational does not have the version 3.1.2 yet on nuget. Are these packages on the way too?

    • Tom Gruszowski 0

      Looks like it’s fixed, re-update packages

      • Rajasekar Shanmugam 0

        Thank you Tom. Yay !!! All our services in 3.1.2 ! Awesome.

  • Me Gusta 0

    Out of curiosity, what are the plans for Windows ARM64 support?

  • Dean Jackson 0

    Is it possible to prevent the creation of the “runtimes” folder in the output folder (netcoreapp3.0 for me since I’m using Core 3.0) when building/compiling an ASP.Net Core app within Visual Studio? The runtimes folder has subfolders like Unix that I don’t need. I understand the purpose of Core is to run multi-platform, but if you are only going to create Core apps for Windows x64, can you prevent this folder?

    • Ashokkumar Ramraj 0

      Self-Contained Deployment is the way to go.

      • Dean Jackson 0

        I want to save some disk space when building/compiling, but thanks anyway. Publishing/deployment is a different thing which doesn’t help when building. It doesn’t make sense that the extra Unix folder would get created during build, instead it should get created if I try to publish to a Unix machine.

        • Daniel Lo Nigro 0

          If you use dotnet build -r windows-x64 then it should only produce Windows artifacts. Not sure where the equivalent setting is in Visual Studio.

  • Steve Hueners 0

    From a current win 10 box I’ve run both the hosting bundle and the .NET Core Runtime 3.1.2 but dotnet –version still reports 3.1.101. I even went so far as to -gasp- reboot. The installers are unequivocally reporting success. Subsequent attempts have offered ‘repair’ so at least part of the install is recognizing 3.1.2.

Feedback usabilla icon