Microsoft.Bcl.AsyncInterfaces

[Davilon85]

Hi,

after version 1.0.123 your package, with framework 4.6.*, is requesting Microsoft.Bcl.AsyncInterfaces >= 5.0.0 and System.Threading.Channels >= 5.0.0?
And latest version is requesting 7.0.0 of these packages..

Why are you requesting Net5 or Net7 packeges also for framework 4.6.*?

[mgravell]

We're not. We're requesting the current package for something that is shipped out-of-box (i.e. not part of the runtime). This is not only supported, but recommended (I've checked with the runtime team). The packages have multi-TFM builds and fully support netfx etc - that's kinda the point of their existence (they're effectively empty packages for net7, etc)

[Davilon85]

Ok, but why latest version of this nuget package doesn't reference the same Microsoft.Bcl.AsyncInterfaces and System.Threading.Channels as the 1.0.123 version with framework 4.6.*?

[mgravell]

Because the v1 version is in minimal deployment mode and the "bar" for making any change is very much higher. It isn't true for Microsoft.Bcl.AsyncInterfaces", but for some of these external libraries, the latest versions do not have support for net46*, so any attempt to do a lib update would be risky and inconsistent. The supportable positions are "do it properly/all" and "leave it alone"; v1 gets the "leave it alone" treatment, v2 gets the "do it properly/all".

[Davilon85]

What do you mean with "V1" and "V2"?

[mgravell]

Oh, sorry, my bad - I was thinking in terms of protobuf-net, not protobuf-net.Grpc - my bad, too many repos!

In this case, then; because we've chosen to update the dependency to use the latest versions. That's allowed, expected, and normal.

Let me turn the question around: what is your concern here? What is the issue?

Again, emphasis: in this case, being v7 doesn't mean "this is the .net 7 specific version", it means "this is the current version, which happens to be numbered 7 because it is easier for MS to align numbers that way". The current version still targets and supports netfx.