Microsoft.Extensions.Hosting 2.2 fails to use Microsoft.Extensions.Hosting.Abstractions 3.0

Describe the bug

While this does seem obvious that version 2.2 of Microsoft.Extensions.Hosting will not work with 3.0 of Microsoft.Extensions.Hosting.Abstractions The nuget package published https://www.nuget.org/packages/Microsoft.Extensions.Hosting/ says it will take ANY version equal or higher than 2.2.

https://www.nuget.org/packages/Microsoft.AspNetCore.App/ will NOT take version 3.0 however.

So if you take a dependency on https://www.nuget.org/packages/Microsoft.AspNetCore.App/ and obey the version specifications…it would appear that:

https://www.nuget.org/packages/Microsoft.AspNetCore.App/ - 2.2.7 https://www.nuget.org/packages/Microsoft.Extensions.Hosting/ - 2.2 https://www.nuget.org/packages/Microsoft.Extensions.Hosting.Abstractions/ - 3.0

Are all completely compatible…but i don’t believe they are.

I get an error stating Unhandled Exception: System.TypeLoadException: Method 'UseServiceProviderFactory' in type 'Microsoft.Extensions.Hosting.HostBuilder' from assembly 'Microsoft.Extensions.Hosting, Version=2.2.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' does not have an implementation.

i am using paket for dependency management here not the standard nuget clients.

[forki]

Unfortunately nuget.org does not allow to change version ranges after a package was released. So not much that can be done about it. In paket we will add a new mode which will be a bit more conservative, but MS could also try to be more forward looking in their range definitions. I mean its almost certain that next major will be breaking. This will break max resolution again. In nuget and Paket.

[DamianEdwards]

We’ve attempted using ranges before and unfortunately without a crystal ball or time machine it’s impossible for us to get right ahead of time, and each time we attempted to we simply blocked otherwise compatible packages from being used together and thus causing lots more people pain than if we’d just left them off, as by far most people appreciate and understand that it’s best to keep related packages on the same aligned version.

Retroactively adding ranges once we know there is a break in a given API is (by the .NET Core policy definition) a servicing event, due to the fact that @forki pointed out. We’d have to ship a patch to the package to update the range. We simply haven’t seen enough cases of this being a big issue to warrant that given the number of packages we ship as part of .NET Core (literally hundreds) and the effort that would be required to ensure they always reflect their upper bounds of compatibility.