aspnetcore: Microsoft.Extensions 3.0 are incompatible with aspnetcore 2.2

Describe the bug

I have a netstandard2.0 class library deployed via NuGet. It depends on Microsoft.Extensions.Configuration and other Extensions packages. I upgraded the dependency references to 3.0.

After this upgrade I can use my class library from aspnetcore 2.1 and aspnetcore 3.0 projects. But I can not use it from aspnetcore 2.2 projects because of version limitations in the Microsoft.AspNetCore.App metapackage. Specifically because all dependencies are bounded to 2.3.0 so 3.0.0 is unavailable.

Basically, it appears that aspnetcore 2.2 is broken, at least in terms of using the new .NET Core 3.0 dependencies.

As an open source library author I’m not sure what to do? Force my user base to move from 2.2 back to 2.1? Or forward to 3.0?

I don’t see a way to create a NuGet package that supports 2.1, 2.2, and 3.0. I can support 2.1 and 3.0, or I can continue to use the pre-3.0 dependencies and support all three versions of aspnetcore (but obviously only sort of supporting 3.0).

Expected behavior

I would expect that there’s some way to create a netstandard2.0 library, put it in a NuGet package, and have it support aspnetcore 2.1, 2.2, and 3.0.

At the very least I hope that the product team thought through this problem space and has a recommended workaround or solution so aspnetcore 2.2 projects aren’t just totally broken with the release of 3.0.

Possible workaround

On further research and conversation via Slack, there are a couple workarounds for people using aspnetcore 2.2.

Switch the Microsoft.AspNetCore.App reference to Microsoft.AspNetCore.All because the “.All” metapackage doesn’t have the upper bound version limits
Replace the Microsoft.AspNetCore.App reference with references to all the packages you are using in your project (far more work, but provides more control)

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 4
Comments: 39 (18 by maintainers)

Most upvoted comments

Specifically, I’d hope that Nc5 can’t reference Nc3 or Ns2 libraries - avoiding the otherwise nearly inevitable dependency conflicts.

You were kidding, right? Because that would be absolutely terrible 🤣

kevinchalet on Sep 25, 2019

Everyone hears me blaming .NET Standard. I don’t mean to “blame” it, as much as point out that due to the way it integrates with NuGet targeting, it is now obsolete for people like me who have dependencies in our packages. My next step is to create netcore3 versions of my projects and add those assemblies to my NuGet packages, so as people move to netcore3 they’ll stop relying on anything to do with netstandard.

That’s not blame. That’s just an observation of reality.

I totally agree with you on the Extensions compatibility. I can see where people will be using the 2.2 versions for years - up to the point that host apps (ASP.NET, WPF, etc.) start using a future-and-incompatible version of Extensions.

Or maybe not years? Maybe that’ll happen with .NET 5. Time will tell - but when Extensions (especially config and DI) become incompatible that’ll cause a whole lot of pain for people.

Actually - to riff on that a bit - aren’t we using semver now? So if 3.0 is backward compatible with 2.x, then why is it 3.0?

Isn’t this really the core of the problem I’m discussing here? That a totally compatible version was released as a major point version instead of a minor version? If it is compatible then it wasn’t breaking, so the major number should have stayed the same.

rockfordlhotka on Sep 25, 2019

I’m not intending to conflate it with netstandard as much as NuGet targets. I wish the decision had been made (or will be made) to have a rolling set of NuGet targets that are platform independent, like netstandard, but that roll slowly forward over time.

How exactly does this fix things? As I said earlier, imagine a world where .NET Core is the only thing on the planet, we’d be having this same discussion. To be even more specific, because ASP.NET Core depends on these extensions, it ends up being problematic for package authors to take dependencies on newer ones (in older versions of ASP.NET Core).

That isn’t the issue the problem is that you can’t pivot based on dependencies. Today TFM is the only tool you have to pivot single package for “multiple things”. Luckily ASP.NET Core targets netcoreapp so you have a way out. Otherwise you only real options are:

Change the package id
Multi target
Use the lowest compatible version

This is one of the big reasons we tried our best to get rid of 3rd party packages in the shared framework. The less things you depend on less the chance of conflict.

davidfowl on Sep 25, 2019

If you want to support all of ASP.NET Core 2.1, 2.2 and 3.0, then your best bet is to cross-target netstandard2.0 and netcoreapp3.0.

ASP.NET Core 3.0 only runs on netcoreapp3.0, so you can make that build exclusive to this version. This also allows you to conditionally reference the framework reference for ASP.NET Core (so you can depend on its stuff).

For ASP.NET Core 2.1 and 2.2, you target netstandard2.0 and reference the 2.1 packages. This unfortunately means that you cannot depend on features that were introduced with 2.2 but that is going to run out of support in a few months anways (while 2.1 stays relevant).

So you would do it like this:

<PropertyGroup>
    <TargetFrameworks>netcoreapp3.0;netstandard2.0</TargetFrameworks>
    …
</PropertyGroup>

<ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp3.0'">
    <!-- Just reference the full framework -->
    <FrameworkReference Include="Microsoft.AspNetCore.App" />
</ItemGroup>

<ItemGroup Condition="'$(TargetFramework)' == 'netstandard2.0">
    <!-- Reference what you need -->
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.1.0" />
</ItemGroup>

For Microsoft.Extensions.*, you will effectively be limited to 2.x packages with ASP.NET Core 2.x. Even if the 3.0 versions still target .NET Standard 2.0, ASP.NET Core is built against 2.x, so you will need that for compatibility.

poke on Oct 22, 2019