Understanding NuGet Package dependecies from Nuget.org

Question

I am a bit confused as how to interpret the dependencies list available on nuget.org and in the NuGet Package Manager in Visual Studio...

Sometimes, the list contains frameworks and a sub-list of dependencies per framework. Sometimes it does not contain the framework I have targeted for a particular project at all, how do I interpret this?

For example, this package's latest stable version is 7.0.5. I have chosen to only update my version to 6.0.16 because that is the latest version which mentions net6 as a dependency.

Versions 7 and above only mention net7.0 with dependencies, hence why I only dare to update to latest 6.X.X. Is my interpretation correct? Should I only update to the latest version mentioning net6 in the dependecy list (when my project targets net6), or can I update to the 7.X.X versions anyway?

Answer 1

A package author can choose what target framework monikers (TFMs) to support; this can be diverse or ultra-specific. In this case (Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore), they have gone "specific", with the v6 versions of the library only targeting net6, v7 versions of the library only targeting net7, etc; so yes, your interpretation is correct and 6.0.16 looks to be the latest you can use with .net 6; if you attempt to install a v7 version of the lib, it should fail to install the package and/or build, because something targeting net7 could be using APIs that simply do not exist in net6, giving runtime failures - the package system attempts to protect you from that.

Now, it might be that the package could work on net6, but targeting multiple frameworks is effort that requires testing, and may involve code changes (in particular #if sections or similar, to use better approaches when available, or fallback approaches when not). It is not unreasonable for authors to say, more simply:

The vOlder version is what it is - we may supply out-of-band updates for security fixes or bugs that cross a certain threshold, and you can keep using vOlder with your netOlder applications, but if you want newer features you'll need to use vNewer on netNewer.

This is on a per-package basis, and many packages are far more diverse in what they target, either by having a wide range of TFMs, or by having wide-reaching targets such as netstandard2.0 (which in theory works on a wide range of platforms, by virtue of only consuming a common intersection of APIs).