NuGet Package Manager attempting to add .NET 5.0 updates to .NET Core 3.1 application

[SoftCircuits]

When I go into Tools | NuGet Package Manager | Manage NuGet Package for Solution, it shows me there are 12 updates available.

But when I attempt to update them all, I get errors.

NU1202: Package Microsoft.VisualStudio.Web.CodeGeneration 5.0.0 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package Microsoft.VisualStudio.Web.CodeGeneration 5.0.0 supports: net5.0 (.NETCoreApp,Version=v5.0)
NU1202: Package Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore 5.0.0 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore 5.0.0 supports: net5.0 (.NETCoreApp,Version=v5.0)
NU1202: Package Microsoft.VisualStudio.Web.CodeGeneration.Utils 5.0.0 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package Microsoft.VisualStudio.Web.CodeGeneration.Utils 5.0.0 supports: net5.0 (.NETCoreApp,Version=v5.0)
NU1202: Package Microsoft.VisualStudio.Web.CodeGeneration.Contracts 5.0.0 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package Microsoft.VisualStudio.Web.CodeGeneration.Contracts 5.0.0 supports: net5.0 (.NETCoreApp,Version=v5.0)
NU1202: Package Microsoft.VisualStudio.Web.CodeGenerators.Mvc 5.0.0 is not compatible with netcoreapp3.1 (.NETCoreApp,Version=v3.1). Package Microsoft.VisualStudio.Web.CodeGenerators.Mvc 5.0.0 supports: net5.0 (.NETCoreApp,Version=v5.0)
Package restore failed. Rolling back package changes for 'SolutionName'.

I can see there are incompatibility issues between .NET Core 3.1 and .NET 5.0 but I don't know why.

Why is NuGet Package Manager trying to add .NET 5.0 updates to a .NET Core 3.1 application?

UPDATE

I kind of preferred to stay with .NET Core 3.1 but decided to try updating the project to .NET 5.0 and see what happened.

After updating the project, I tried to update the packages again. This time I get a different error.

System.NullReferenceException: Object reference not set to an instance of an object.
   at NuGet.PackageManagement.UI.UIActionEngine.<>c.<ResolveActionsForUpdateAsync>b__9_0(PackageIdentity package)
   at System.Linq.Enumerable.WhereListIterator`1.MoveNext()
   at System.Linq.Enumerable.Any[TSource](IEnumerable`1 source)
   at NuGet.PackageManagement.UI.UIActionEngine.<ResolveActionsForUpdateAsync>d__9.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
   at NuGet.PackageManagement.UI.UIActionEngine.<>c__DisplayClass11_0.<<PerformActionImplAsync>b__0>d.MoveNext()
Time Elapsed: 00:00:00.0111119
========== Finished ==========

I'm really not sure why I'm getting any of these errors. Are there known issues? Can anyone help me understand why things aren't working?

Note: Before upgrading my application to .NET Core, I also updated Visual Studio to version 16.8.2.

Further technical details

• ASP.NET Core version 3.1
• Visual Studio Version 16.8.0 (Windows 10)

.NET SDK (reflecting any global.json):
Version: 5.0.100
Commit: 5044b93829

Runtime Environment:
OS Name: Windows
OS Version: 10.0.19041
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):
Version: 5.0.0
Commit: cf258a14b7

.NET SDKs installed:
3.1.401 [C:\Program Files\dotnet\sdk]
5.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[mkArtakMSFT]

Thanks for contacting us.
This is a great feedback to share with the NuGet team.
@rrelyea do you happen to know whether https://github.com/nuget/home is the right repo to transfer this to?

[Pilchie]

Also tagging @aortiz-msft

[aortiz-msft]

This seems like a dupe of NuGet/Home#9882. Would you please see the conversation there, upvote and add comments as needed? A couple of work-arounds are also discussed there.

[Pilchie]

I don't think that issue is the same as this. This is the fact that there are packages whose version should match the TFM they are using as part of .NET Core/.NET 5 and ASP.NET Core, but the package manager UI always prompts people to upgrade them.

AFAIK, there is no way for us as package authors to prevent this.

[SoftCircuits]

This seems like a dupe of NuGet/Home#9882. Would you please see the conversation there, upvote and add comments as needed? A couple of work-arounds are also discussed there.

It looks like that may be the same as my second issue. But the original issue is different.

[aortiz-msft]

@zkat - Would you please take a look at the original issue reported?

[zkat]

@SoftCircuits the first issue is more like NuGet/Home#10309 -- basically no, we just don't support this sort of upgrade filtering right now. We just go by version, which means you can end up with incompatibilities like these.

[SoftCircuits]

@SoftCircuits the first issue is more like NuGet/Home#10309 -- basically no, we just don't support this sort of upgrade filtering right now. We just go by version, which means you can end up with incompatibilities like these.

Well, I wasn't trying to do any filtering. The package manager was showing those as available updates. I really don't think it should be basically recommending incompatible updates that will cause errors. Neither do I think I should have to go through each one to try and figure out which ones will be compatible and which ones won't. This is the very thing that the package manager seems to be there for.

Getting all these errors by basically following prompts or alerts seems like a problem from where I'm standing.

[zkat]

I agree that it's an issue! That's something we intend to fix, it's just the way it works right now. It definitely makes upgrades and even regular ol' installs harder to get right, especially when we're at framework boundaries like 3.1 -> 5.0.

[hiezust]

Do you know of any issues on using 5.0 nuget packages on a .NET Core 3.1 WebAPI?

It seems that multiple nuget packages can be upgraded to version 5. For example:

[Pilchie]

NuGet doesn't block it, and it's likely that it will work, but it's not what we typically test. Your best bet is to use the latest patch NuGet packages that correspond to the major.minor of your target.

[nicoleta-scrimint]

Is it possible that NuGet to block updating .Net Core 3.1 packages to 5.X.X versions? Based on your answer, we know that .Net Core 5.X.X NuGet packages are not guaranteed to work with .Net Core 3.1.
It would be nice that NuGet to not let update NuGet packages to versions between big impact versions like .Net Core 3.1 or .Net 5, 6 because it is required more work than a simple NuGet package update to migrate to another .Net Core release version based on the Microsoft upgrade guide from https://docs.microsoft.com/en-us/aspnet/core/migration/31-to-50?view=aspnetcore-5.0&tabs=visual-studio.

[Pilchie]

That's a NuGet request. Unfortunately, there isn't a good way to express it right now.

[rrelyea]

NuGet has 2 related things on our backlog...they are complicated features to implement, but we aspire to add support.
we don't think package authors need a new way to express...nuget client (and maybe server) need to get smarter...

1. search by tfm -- search should be able to only show packages that are compatible to your project - Package Search should limit results to compatible packages for target project(s) NuGet/Home#4071
2. update by tfm -- search shouldn't recommend updating packages that won't be compatible due to TargetFramework compatbility - Package Compatibility Filtering (for update) NuGet/Home#2084

[Pilchie]

Actually, I don't think those features will necessarily address this situation. In this case we're talking about a package where both the 3.1 and the 5.0 version target .NET Standard 2.0, but if you are running on .NET Core 3.1, you should use the 3.1 version of the package, and if you're running on .NET 5, you should use the 5.0 version.

[SoftCircuits]

Actually, I don't think those features will necessarily address this situation. In this case we're talking about a package where both the 3.1 and the 5.0 version target .NET Standard 2.0, but if you are running on .NET Core 3.1, you should use the 3.1 version of the package, and if you're running on .NET 5, you should use the 5.0 version.

Yes, I have a bunch of NuGet packages I've published that use .NET Standard. I need to figure out how to add .NET 5.0 versions without losing the old ones (for people who haven't jumped to .NET 5.0 yet). Seems like some kind of manager for this, both for creating and consuming packages, is needed.

[Pilchie]

@SoftCircuits - you should be able to do that by having TFM specific assets in your package.

[SoftCircuits]

@Pilchie Not sure what TFM refers to, but I know there's a way to put different versions in the same package. But Visual Studio won't do it for you. You have to manually edit the package file.

[AraHaan]

@SoftCircuits I would recommend dropping .NET Standard and instead ship only .NET Core 3.1 and 5.0 version and in the csproj you can do like:

<PackageReference Include="PackageName" Version="5.0.*" Condition="'$(TargetFramework)' == 'net5.0'" />
<PackageReference Include="PackageName" Version="3.1.*" Condition="'$(TargetFramework)' != 'net5.0'" />

for every package you need to use from the runtime feeds.

the *'s represent wildcard version numbers for any patch build that later gets released.

However what if I want to use something like System.Runtime v5.0.0 inside of .NET Framework 4.7.2 due to things like System.OperatingSystem.IsWindowsVersionAtLeast() or even System.OperatingSystem.IsWindows() looking cleaner than System.Environment.OSVersion.Version depending on the project?

[SoftCircuits]

@AraHaan Where am I using .NET Standard here?

[AraHaan]

Yes, I have a bunch of NuGet packages I've published that use .NET Standard. I need to figure out how to add .NET 5.0 versions without losing the old ones (for people who haven't jumped to .NET 5.0 yet). Seems like some kind of manager for this, both for creating and consuming packages, is needed.

You said you have a ton of packages that use .NET Standard. If you are only targeting people that use .NET Core 3.1 and .NET 5 you could get away with targeting only those TFMs.

However since .NET Standard depending on the .NET Standard version (if 2.1+ you do not need to include .NET Framework, if 2.0+ you got to include .NET Framework 4.6.1 (you could get away with only providing a net461 folder for the .NET Framework and anyone using newer .NET Framework versions will consume the net461 build)).

Also now that I think about mine I think my projects could drop .NET Standard as well too.

[jefflill]

If I'm following this all, it appears that some or all of the Microsoft.Extensions.* v5.0.0 packages are not compatible (or tested) against .NET Core 3.1 applications. In our case, we have a NET Standard 2.0 library including these v5.0.0 packages and then consumed this library in a .NET Core 3.1 app (as well as .NET Framework based xUnit tests).

This means that I was able to include these NET Standard 2.0 Microsoft.Extensions.* packages into my .NET Standard 2.0 library making my library incompatible with .NET Core 3.1 apps.

Question:

Which Microsoft packages should NET Standard 2.0 libraries avoid to maintain compatibility with .NET Core 3.1?

Can we consider that any Microsoft.* or System. with version greater than v5.0.0 as being incompatible with .NET Core 3.1?

[AraHaan]

System.Text.Json works despite being used for .NET 5 or Core 3.1 even if it's a preview version of 6.0.0 of it. But that is a rare thing however and targeting a framework that comes with System.Text.Json (like .NET 5) could give build warnings, however at runtime it works anyway 😄.

[nicoleta-scrimint]

NuGet doesn't block it, and it's likely that it will work, but it's not what we typically test. Your best bet is to use the latest patch NuGet packages that correspond to the major.minor of your target.

What version should we use for packages like System.Security.Permissions and System.ComponentModel.Annotations which do not have a version for 3.1.X, in .Net Core 3.1 applications? The latest version under 5.X.X is 4.7.0. Should we interpret that the latest version under 5.X.X is for .Net Core 3.1?

I also observe that the package Microsoft.AspNetCore.Mvc.Versioning version 5.0.0 also targets .Net Core 3.1. Does it mean that it can be used in a .Net Core 3.1 application?

Thank you!

[Pilchie]

What version should we use for packages like System.Security.Permissions and System.ComponentModel.Annotations?

Packages built out of corefx/runtime have done different (probably better 😉 ) things. @ericstj or @ViktorHofer could describe that.

Microsoft.AspNetCore.Mvc.Versioning version 5.0.0

That package is not owned by the team - it's a package made by an individual with no affiliation to the team, and I can't speak to how it versions. It's unfortunate that the package was created before NuGet allowed reserving package prefixes. I suggest asking on it's page.

[ericstj]

What version should we use for packages like System.Security.Permissions and System.ComponentModel.Annotations?

These packages are made to work on any of the frameworks they support, so the 5.x era packages work on netcoreapp3.1 (just like they work on .NETFramework and even older versions of .NETCore) however we test and service them in release bands. So all the 4.7.x packages are tested together, and supported for the same period of time as the release from which they came. By only updating within a release band you get minimal churn and a consistent servicing timeline. This is what we recommend if you are trying to minimize change while remaining in support.

The 5.0.0 packages will work when used on 3.1 but we don't test them there, so you may find issues. We'd want to hear about those issues as they could represent compatibility problems in that or a future release. Take for example System.Text.Json and other System.Diagnostics.DiagnosticSource: these packages are undergoing active development and feature work in 5.0 and 6.0. These packages are used by other libraries in the ecosystem which target netstandard. We expect these packages to be used across all in-support frameworks (.NETFramework versions, .NETCore 2.1, 3.1, and 5.0).

Also, to comment specifically on those packages

System.Security.Permissions

This package is entirely legacy code with empty implementation types. It's solely provided as a no-op implementation of CAS. Avoid using it entirely if you can.

System.ComponentModel.Annotations

This package is providing a bridge between API surface in .NETFramework and .NETCore, It is part in both frameworks and doesn't require a package. Additionally, it is part of .NETStandard 2.1. You only need reference this package if you're producing a netstandard2.0 or lower library. If you're targeting any other framework you shouldn't need this package as you can rely on the types provided by the framework.

[ghost]

Thank you for contacting us. Due to a lack of activity on this discussion issue we're closing it in an effort to keep our backlog clean. If you believe there is a concern related to the ASP.NET Core framework, which hasn't been addressed yet, please file a new issue.

This issue will be locked after 30 more days of inactivity. If you still wish to discuss this subject after then, please create a new issue!

[AraHaan]

Has this been fixed? I feel like people forgot about this issue until now.