.NET May 2022 Update - .NET 6.0.5, .NET 5.0.17, and .NET Core 3.1.25

[rbhanda]

Release Notes
6.0.5
5.0.17
3.1.25

Please report any issues you find either by responding to this issue, creating a new issue or creating a new issue in one of the following repos:

• dotnet/aspnetcore - for ASP.NET Core questions
• dotnet/efcore - for Entity Framework Core questions
• dotnet/sdk - for CLI tools and questions
• dotnet/runtime - for runtime, API, or installer issues and questions
• dotnet/winforms - for WinForms issues
• dotnet/wpf - for WPF issues
• nuget/home - for NuGet questions and issues

Distro	6.0.5	5.0.17	3.1.25
Ubuntu 18.04	✅	✅	✅
Ubuntu 20.04	✅	✅	✅
Ubuntu 21.04	✅	✅	✅
Centos 7	✅	✅	✅
Debian 10	✅	✅	✅
Debian 11	✅	✅	✅
Fedora 33	✅	✅	✅
Fedora 34	✅	✅	✅
OpenSUSE 15	✅	✅	✅
Oracle	✅	✅	✅

Note: This list refers to the Microsoft-provisioned feeds (packages.microsoft.com) and does not in any way represent direct availability in distros (eg RHEL, Fedora).

Known Issues

If there are any more issues with this release we will track them here and check issues off as they're resolved. See the linked issues for details on progress and resolution details.

[inloox-dev]

Hello,

in our CI/CD pipelines we´re using the following YML step to get the latest .Net SDK Version:

- task: UseDotNet@2 displayName: 'Use .NET Core sdk' inputs: packageType: 'sdk' version: '6.0.x' includePreviewVersions: true

Until yesterday we recieved version 6.0.202 via this task. From today it´s 6.0.300.

Now all our Builds have a massive amount of warnings regarding the Microsoft Code Analysis. It looks like a missing assembly ('Microsoft.CodeAnalysis.CodeStyle.dll').

##[warning]CSC(0,0): Warning CS8032: An instance of analyzer Microsoft.CodeAnalysis.MakeFieldReadonly.MakeFieldReadonlyDiagnosticAnalyzer cannot be created from C:\hostedtoolcache\windows\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CodeStyle.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.. CSC : warning CS8032: An instance of analyzer Microsoft.CodeAnalysis.MakeFieldReadonly.MakeFieldReadonlyDiagnosticAnalyzer cannot be created from C:\hostedtoolcache\windows\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\codestyle\cs\Microsoft.CodeAnalysis.CodeStyle.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=4.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.. [f:\a\1\s\src\XX\XX.csproj]

[edwiles]

Our builds are returning extra code analysis violations since upgrading to .NET Core 6.0.5 (i.e. SDK 6.0.300). These warnings are not present in SDK 6.0.203.

e.g. The line List<string> a = new(b.C); now returns warning IDE0028: Collection initialization can be simplified

e.g. The line var a = new B { C = d, E = new F { G = 100 } }; now returns warning IDE0017: Object initialization can be simplified

[bmilsom]

Hello,

We have some CI/CD builds which have started failing after the release of dotnet 6.0.300 which seems to be related to central package management.

The error we are getting is:
error NU1507: There are 2 package sources defined in your configuration. When using central package management, please map your package sources with package source mapping (https://aka.ms/nuget-package-source-mapping) or specify a single package source.

Yesterday this was not a problem (with version 6.0.202), and after investigation we found that our builds started working again when specifying verison 6.0.202 to be installed. We are using the actions/setup-dotnet@v2 action to achieve this. Previously we installed the latest dotnet in our workflow yml files like so:

  uses: actions/setup-dotnet@v2
  with:
    dotnet-version: |
      3.1.x
      5.0.x
      6.0.x

but we have reverted it like this for now:

  uses: actions/setup-dotnet@v2
  with:
    dotnet-version: |
      3.1.x
      5.0.x
      6.0.202

These are running on the ubuntu-latest GitHub runners.

[jaredpar]

@jmarolf , @sharwell, @terrajobst

[yophilav]

Release Notes 6.0.5 5.0.17 3.1.25

Please report any issues you find either by responding to this issue, creating a new issue or creating a new issue in one of the following repos:

• dotnet/aspnetcore - for ASP.NET Core questions
• dotnet/efcore - for Entity Framework Core questions
• dotnet/sdk - for CLI tools and questions
• dotnet/runtime - for runtime, API, or installer issues and questions
• dotnet/winforms - for WinForms issues
• dotnet/wpf - for WPF issues
• nuget/home - for NuGet questions and issues

Distro 6.0.5 5.0.17 3.1.25
Ubuntu 18.04
Ubuntu 20.04
Ubuntu 21.04
Centos 7
Debian 10
Debian 11
Fedora 33
Fedora 34
OpenSUSE 15
Oracle
Note: This list refers to the Microsoft-provisioned feeds (packages.microsoft.com) and does not in any way represent direct availability in distros (eg RHEL, Fedora).

Known Issues

If there are any more issues with this release we will track them here and check issues off as they're resolved. See the linked issues for details on progress and resolution details.

@rbhanda
Could you update the link for 3.1.25 please?
The link for 3.1.25 doesn't work.
I think there is a typo in the url https://github.com/dotnet/core/blob/main/release-notes/3. "0" /3.1.25/3.1.25.md

[dstahl-axion]

I'm seeing some new failures as well.

I have a project with the following PropertyGroup in the .csproj file.

  <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
  </PropertyGroup>

When I run dotnet restore on this project, a warning about conflicting Nuget packages is being treated as an error and failing. This did not happen in the 6.0.202 SDK but does happen in 6.0.300. Were there changes to how configurations are handled during dotnet restore?

The specific warning/error is NU1701 and it's happening because a package is being restored as net461 for a netstandard project. I'm working to fix that, but this warning/error/failure did not happen on a previous SDK so I'm reporting it here.

[hasan-akgun-sveasolar]

Seems like MSBuildTreatWarningsAsErrors and TreatWarningsAsErrors were working/handling differently and enabling TreatWarningsAsErrors didn't have any effect on MSBuild warnings, now it has.

[dcwhittaker]

Closing in favor of #7536