15

I was looking for some NuGet updates about my project libraries. I see that there are a lot of Microsoft libraries update to v5.0.0.

enter image description here

Based on my knowledge I think these are new dependencies released with .Net 5.0 and I'm not sure that I can update these libraries to latest version using .Net Core 3.1 project.

Can I update to v5.0.0 libraries even if I'm using/building a .Net Core 3.1 project?

E.Benedos
  • 1,585
  • 14
  • 41
  • If you already have source control in place (like Git), an experiment can tell you all. – Lex Li Nov 11 '20 at 19:43
  • But this not guarantee me that it is 100% production proof. Microsoft documentation does not explain nothing about that – E.Benedos Nov 11 '20 at 20:05
  • Nothing? https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/plan#supported-platforms EF Core 5 supports .NET Core 3.1 officially (though Microsoft should update this page to make it clearer). – Lex Li Nov 11 '20 at 20:35
  • Thanks @Lez Li, I was not able to find this page and I’m agree with you about it can be more clear. Anyway this partially answer my question that is not only about EF Core. What about other system libraries? I think Microsoft can be more clear about this topic, because in my opinion it is as simply as important for developers that need to update only packages after .net 5 release. – E.Benedos Nov 11 '20 at 21:30
  • For Microsoft packages alone, if anything is .NET 5 only, they should target only `net5` instead of `netstandard2.1` (which .NET Core 3.1 can consume). Though more clarification is required from Microsoft, I think we already have some clues. – Lex Li Nov 11 '20 at 22:17
  • I have some Net 4.8 projects that use the same common libraries that I am using for Net Core. So these common libraries are targeted to netstandard2.0. and can't change them to Net5 now. But they work ok with both. – Serge Nov 11 '20 at 22:39
  • I would like to think that you can treat these updates just like any other NuGet package update. Be careful though, as semantic versioning says that a change of the major version number *may* introduce breaking changes. For instance, if such a package only depends on .net standard 2.0, then it is perfectly reasonable to use the package in net48. If the package upgrade really breaks in such a way that you can no longer use it in net48, then the package should have dropped support for net standard 2.0. – AroglDarthu Nov 13 '20 at 10:34
  • I don't get why there is no official statement or guidance from Microsoft regarding this topic... Maybe it also needs to be distinguished between packages acting as a "Framework" (problematic) or as a "Library" (likely OK to update them and at least try it)? – timmkrause Jun 02 '21 at 10:26

3 Answers3

3

Unfortunately, you cannot update many of these newest Nuget packages to 5.0. The reason being is that the newest Nuget package versions are written primarily for .NET 5, and often times Nuget Package Manager will even prevent you from installing them since there are differences in the APIs. With that said, there may be a few spots where it will allow the installation, but I wouldn't recommend it if you plan to keep the application on .NET Core 3.1. Most likely it could cause some inconsistencies that would be hard to debug. Proceed with caution, or upgrade your projects to .NET 5.

COleson
  • 346
  • 3
  • 9
  • 1
    Unfortunately, packages targeting .NET Standard 2.1 can be consumed by .NET Core 3.1 projects and Microsoft won't block such. With official words like https://learn.microsoft.com/en-us/ef/core/what-is-new/ef-core-5.0/plan#supported-platforms it is also clear that .NET Core 3.1 can use some new packages (if not all). I agree caution is recommended, but "written explicitly for .NET 5" is not true. – Lex Li Nov 11 '20 at 22:13
  • Made a modification to the comment. They are written primarily for .NET 5, with the other target frameworks taking a back seat. Hopefully, that is better stated. – COleson Nov 11 '20 at 22:29
1

I just finished the same. I had 3.1 core application with a lot of 3.1 and NET Standard2.0 libraries projects and just updated all these libraries to the version 5. All libraries were working ok, I could compile them. But I couldn't compile my main Web application. It started to give some strange errors that some staff needs .net5. Maybe it could be fixed but I didn't see much sense to waste my time since in any case I was planning to move to net5 in a couple of days. So I just decided to move to net5 immediately. I had installed net 5.0 SDK and change target framework of my application to net5.0. Now everything is working fine and I am happy with my net5.0 application. I have some Net 4.8 projects that use the same common libraries that I am using for Net Core. So these common libraries are targeted to netstandard2.0. and can't change them to Net5. Now all these Standard2.0 projects still work with my net5.0 web application without any problem. Since I didn't have any problems with my previous version 3.1.9 I DON'T RECOMEND to update libraries to 5.0 if YOU DON'T PLAN to move your application to Net5.0. You can get more problems after this then you can gain from this update.

Serge
  • 40,935
  • 4
  • 18
  • 45
  • "But I couldn't compile my main Web application. It started to give some strange errors that some staff needs .net5." That requires further digging and can be caused by something else. – Lex Li Nov 11 '20 at 22:14
  • It worked Ok before I updated it. You are right maybe it could be fixed but I didn't see much sense to waste my time since I was planning to move to net5 in a couple of days. I just moved immediately. And since I didn't have any problems with my previous version 3.1.9. So I don't see much sence to move libraries to 5.0 and spend a lot of time to fix it, if I don't gain anything with this. – Serge Nov 11 '20 at 22:20
0

You should report such (VS for Mac and VS for Windows) as product defects to Microsoft, as many of the new 5.0 packages are targeting net5 solely, and not applicable to netcoreapp3.1.

Try to use outdated tool to check package updates, which is much more reliable,

https://github.com/dotnet-outdated/dotnet-outdated

Lex Li
  • 60,503
  • 9
  • 116
  • 147