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.
- .NET Core 3.1.2 and .NET Core SDK ( Download | Release Notes )
- .NET Core 3.0.3 and .NET Core SDK ( Download | Release Notes )
- .NET Core 2.1.16 and .NET Core SDK ( Download | Release Notes )
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.
- dotnet/core/sdk: .NET Core SDK
- dotnet/core/aspnet: ASP.NET Core Runtime
- dotnet/core/runtime: .NET Core Runtime
- dotnet/core/runtime-deps: .NET Core Runtime Dependencies
- dotnet/core/samples: .NET Core Samples
Note: You must pull updated .NET Core container images to get this update, with either docker pull or docker build –pull.
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.
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?
Self-Contained Deployment is the way to go.
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.
If you use
dotnet build -r windows-x64then it should only produce Windows artifacts. Not sure where the equivalent setting is in Visual Studio.Out of curiosity, what are the plans for Windows ARM64 support?
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?
Looks like it’s fixed, re-update packages
Thank you Tom. Yay !!! All our services in 3.1.2 ! Awesome.