[BUG] .NET8 support (as well as previous versions) is probably broken starting from v2

[andriibratanin]

I stumbled upon NU1605 error (package downgrade detected) in my project (which targets .NET8 SDK) after installing FusionCache v2.

Checking https://github.com/ZiggyCreatures/FusionCache/blob/main/src/ZiggyCreatures.FusionCache/ZiggyCreatures.FusionCache.csproj:

<TargetFrameworks>netstandard2.0;netcoreapp3.1;net6.0;net7.0;net8.0</TargetFrameworks>

but finding also:

<ItemGroup>
	<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="9.0.0" />
</ItemGroup>

Reason:
Version 9 of "Microsoft.Extensions.Caching.Memory" NuGet package (as well as others) is causing NU1603 error in projects targeting .NET8 SDK (and probably 7, 6, etc.).

Arguments:

• it is probably not right to reference NuGet packages of .NET9 while declaring support only for .NET8 max.
• OR we are missing conditional ItemGroup in csproj files, like:

<ItemGroup Condition="'$(TargetFramework)' == 'net8.0'">
	<PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="8.0.1" />
	<PackageReference Include="System.Collections.Immutable" Version="8.0.0" /> <!-- not sure if this one is needed -->
</ItemGroup>

[jodydonetti]

Hi @andriibratanin , the version of Microsoft packages is not (necessarily) related to the corresponding .NET version. You can use a main package v9 with .NET 8 or 7.

For example: the package Microsoft.Extensions.Caching.Memory you mentioned is not tied to .NET 9, it can be used on .NET 8, 7, 6 and even earlier versions down to the old .NET Framework 4.6.2, see here:

Can you give me more info about your dependencies?

[andriibratanin]

I agree that versioning discussions are very old: dotnet/extensions#2700 (comment), but I believe the major version should not change

Here is my csproj file header:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>net8.0</TargetFramework>
        <ImplicitUsings>enable</ImplicitUsings>
        <Nullable>disable</Nullable>
    </PropertyGroup>

Here are my dependencies:

        <!--
        .NET Core
        -->
        <!-- https://github.com/dotnet/runtime/releases -->
        <!-- https://github.com/dotnet/extensions/releases -->
        <PackageVersion Include="Microsoft.Extensions.Configuration" Version="8.0.0" />
        <PackageVersion Include="Microsoft.Extensions.Configuration.Json" Version="8.0.1" />
        <PackageVersion Include="Microsoft.Extensions.Configuration.UserSecrets" Version="8.0.1" />
        <PackageVersion Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="8.0.2" />
        <PackageVersion Include="Microsoft.Extensions.Hosting" Version="8.0.1" />
        <PackageVersion Include="Microsoft.Extensions.Hosting.Abstractions" Version="8.0.1" />
        <PackageVersion Include="Microsoft.Extensions.Http" Version="8.0.1" />
        <PackageVersion Include="Microsoft.Extensions.Logging.Console" Version="8.0.1" />
        <PackageVersion Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="8.0.0" />
        <PackageVersion Include="Microsoft.Extensions.Options.DataAnnotations" Version="8.0.0" />
        <PackageVersion Include="Microsoft.Net.Http.Headers" Version="8.0.10" />

Please note I use CPM (central package management), so the notation is a little bit different (PackageVersion tag is used instead of PackageReference)

NU1605 errors are not trivial to investigate. For example, the original error message was:

Error NU1605 : Warning As Error: Detected package downgrade: Microsoft.Extensions.DependencyInjection.Abstractions from 9.0.0 to 8.0.2. Reference the package directly from the project to select a different version. 
 CE.Caching -> Microsoft.Extensions.Caching.StackExchangeRedis 8.0.12 -> Microsoft.Extensions.Logging.Abstractions 9.0.0 -> Microsoft.Extensions.DependencyInjection.Abstractions (>= 9.0.0) 
 CE.Caching -> Microsoft.Extensions.DependencyInjection.Abstractions (>= 8.0.2)
1>------- Finished building project: CE.Caching. Succeeded: False. Errors: 1. Warnings: 0

but it has nothing to deal with Microsoft.Extensions.Caching.StackExchangeRedis:

as the only package referencing .NET9 is FusionCache:

We will be able to see the correct error message only after explicitly setting package versions:

        <PackageReference Include="Microsoft.Extensions.Caching.Abstractions" Version="8.0.0" />
        <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="8.0.1" />
        <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="8.0.2" />
        <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="8.0.2" />

finally resulting in:

Error NU1605 : Warning As Error: Detected package downgrade: Microsoft.Extensions.Caching.Memory from 9.0.0 to 8.0.1. Reference the package directly from the project to select a different version. 
 CE.Caching -> ZiggyCreatures.FusionCache 2.1.0 -> Microsoft.Extensions.Caching.Memory (>= 9.0.0) 
 CE.Caching -> Microsoft.Extensions.Caching.Memory (>= 8.0.1)
1>------- Finished building project: CE.Caching. Succeeded: False. Errors: 1. Warnings: 0

which seems like a dead-end without "partially upgrading" to .NET9

PS: explicitly sticking .NET version with global.json like the following doesn't help:

{
  "sdk": {
    "allowPrerelease": false,
    "rollForward": "latestFeature",
    "version": "8.0.300"
  }
}

[scardenas]

This is happening to me too (same situation exactly). I can't upgrade to v2.

[jodydonetti]

I'm reading about this online to get a better grasp of the best practices (thanks for the links!)

So basically the idea would be to specify, for each TFM in the multi-target list, the package version related to that TFM? So if I have multi-target with .NET 8 and 9, I should specify the dependency on Microsoft.Extensions.Caching.Memory version 8 for .NET 8 and version 9 for .NET 9?

And what about .NET Standard 2.0, what should I do there?

Also, wouldn't this create confusion for users?

I'll take a look at existing Microsoft packages to see if they actually do the same.

I'm trying to understand how this would work with all the edge cases, so any help in exploring the scenarios is appreciated, thanks!

Regarding your specific: case I think you have a direct dependency on one of those packages with a specific version, for example you probably have a direct dependency on Microsoft.Extensions.Caching.Memory v8 and when updating to FusionCache v2 Nuget sees that it would require an upgrade to Microsoft.Extensions.Caching.Memory v9, but it doesn't do that because you have a direct dependency declared which you need to manually update first. Can you try update your Microsoft.Extensions.Caching.Memory dependency to v9 and try again to update to FusionCache v2, to see if that fixes it, and let me know? Thanks!

[jodydonetti]

I'll add: looking for example at the Microsoft.Extensions.Caching.Hybrid package, they ( @mgravell basically) are doing the same thing there:

Another example is System.Text.Json, and they do the same:

Maybe is the direct reference I mentioned? Or maybe something specific about CPM (central package management)?

I'll keep looking into this.

[andriibratanin]

Regarding your specific: case I think you have a direct dependency on one of those packages with a specific version

No, I have no dependency on Microsoft.Extensions.Caching.Memory. In my case NU1605 error is related to Microsoft.Extensions.DependencyInjection.Abstractions package which I have to reference directly due to code requirements.

---

Let me help you to figure how it works

Just create an empty console application or worker service targeting .NET8 and then experiment with installing the following sets of packages (no code changes are required at all):

Case 1: Only FusionCache is installed:

        <!-- Case 1: Only FusionCache is installed - builds ok -->
        <PackageReference Include="Microsoft.Extensions.Caching.StackExchangeRedis" Version="8.0.12" />
        <PackageReference Include="Microsoft.Extensions.Hosting" Version="8.0.1"/>
        <PackageReference Include="ZiggyCreatures.FusionCache" Version="2.1.0" />
        <PackageReference Include="ZiggyCreatures.FusionCache.Serialization.SystemTextJson" Version="2.1.0" />

this builds ok

---

Case 2: FusionCache + DependencyInjection.Abstrations:

        <!-- Case 2: FusionCache + DependencyInjection.Abstrations - build fails -->
        <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="8.0.2" />
        <PackageReference Include="Microsoft.Extensions.Caching.StackExchangeRedis" Version="8.0.12" />
        <PackageReference Include="Microsoft.Extensions.Hosting" Version="8.0.1"/>
        <PackageReference Include="ZiggyCreatures.FusionCache" Version="2.1.0" />
        <PackageReference Include="ZiggyCreatures.FusionCache.Serialization.SystemTextJson" Version="2.1.0" />

this will not build!

---

Now, interesting ones, my counter-arguments:

Case 3: MemoryCache v8 + DependencyInjection.Abstrations (no FusionCache)

       <!-- Case 3: MemoryCache v8 + DependencyInjection.Abstrations - builds ok -->
        <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="8.0.1" />
        <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="8.0.2" />
        <PackageReference Include="Microsoft.Extensions.Caching.StackExchangeRedis" Version="8.0.12" />
        <PackageReference Include="Microsoft.Extensions.Hosting" Version="8.0.1"/>

this builds ok!

---

BUT, as soon as we upgrade the version of MemoryCache to 9 everything breaks:

Case 4: MemoryCache v9 + DependencyInjection.Abstrations:

        <!-- Case 4: MemoryCache v9 + DependencyInjection.Abstrations - build fails -->
        <PackageReference Include="Microsoft.Extensions.Caching.Memory" Version="9.0.1" />
        <PackageReference Include="Microsoft.Extensions.DependencyInjection.Abstractions" Version="8.0.2" />
        <PackageReference Include="Microsoft.Extensions.Caching.StackExchangeRedis" Version="8.0.12" />
        <PackageReference Include="Microsoft.Extensions.Hosting" Version="8.0.1"/>

build fails.

So, unfortunatelly, we are mistaken supposing that stated support of version below 9 is true when we are not actually on .NET9

---

Extensions packages are using Central Package Management with conditionals:

• https://github.com/dotnet/extensions/tree/main/eng/packages
• https://github.com/dotnet/extensions/blob/main/eng/Versions.props
• https://github.com/dotnet/extensions/blob/main/eng/Version.Details.xml

I suppose they run build multiple times (to publish packages for v8, v9, etc.)

[juantxorena]

I'm also hit by this so I cannot upgrade, since we are in the LTS version. I don't really know about packaging and versioning, but as an example, another package I'm using (Grpc.Net.Client) seems to depend on the minimum needed version they need, instead of the latest:

Here is the csproj file. There is this MicrosoftExtensionsLtsPackageVersion thing which I don't know what is it, but it seems relevant:

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.Logging.Abstractions" VersionOverride="$(MicrosoftExtensionsLtsPackageVersion)" />
  </ItemGroup>

That variable is defined in a props file.

[andriibratanin]

Just for reference: here is one more issue reported in Extensions repo regarding v9 packages usage in v8 applications:
dotnet/extensions#5644

[jodydonetti]

Hi all, thanks a lot for all the infos!

I'm trying to understand the best course of action to ease the update for you, without introducing some breaking changes all the others who already updated to v2.

Currently I'm thinking about a couple of options, like:

• downgrading all the package refs to the v8 versions, since it was already like that in v1.4.1 when nobody mentioned any problem
• downgrading all the package refs to an even lower version, since an higher one in the host project or in another package in the same host project would bump automatically anyway
• specify different versions for the refs based on each TFM (so targeting v8 versions for .NET 8, v6 versions for .NET 6, etc)

Currently though I'm not sure which one (or another one) would be the best path.

I'll keep you updated, thanks again for the discussion and the sharing of info.

[jodydonetti]

Meanwhile, I'm trying to see if the .NET community can come up with some help:

• BlueSky
• Twitter
• LinkedIn

Let's see if someone smarter than me can help 🤞

[alexaka1]

Can OP try to upgrade all direct references of Microsoft.* packages to 9.*?
And if not, why not? Afaik you should be upgrading these across major version as well. Don't confuse the package major version with current latest .Net version. They are versioned like this for convenience only, there is actually no runtime blockers as evidenced by the supported frameworks table on nuget.org

Also, why are you locking to the .Net 8 SDK? The SDK itself should be the latest always. The oldest SDK you can need today is .Net 6, but that's because 9 dropped support for building 6. If you develop for .Net 8 today, you need two things. 9 SDK and 8 runtime. This is not relevant to the issue, I'm just curious what is the justification.

[juantxorena]

Can OP try to upgrade all direct references of Microsoft.* packages to 9.*? And if not, why not? Afaik you should be upgrading these across major version as well. Don't confuse the package major version with current latest .Net version. They are versioned like this for convenience only, there is actually no runtime blockers as evidenced by the supported frameworks table on nuget.org

If that is the case, why force depend on the latest version instead of the minimum version needed? If there are no runtime blockers, older versions should work.

In any case, I disagree. In my opinion, 9.* packages are for .NET 9, and 8.* packages are for .NET 8. Take this one, for example (although any other AspNetCore would do). Versions 8.0.11 and 9.0.0 were released 3 months ago. Versions 8.0.12 and 9.0.1 were both released 24 days ago, meaning that the 8.* branch is still maintained. If it was only convenience, they wouldn't have bothered with 8.0.12.

Also, why are you locking to the .Net 8 SDK? The SDK itself should be the latest always. The oldest SDK you can need today is .Net 6, but that's because 9 dropped support for building 6. If you develop for .Net 8 today, you need two things. 9 SDK and 8 runtime. This is not relevant to the issue, I'm just curious what is the justification.

.NET 8 is LTS, .NET 9 isn't. That is the justification in my case (and probably in most of the people who are still with .NET 8). As per above, .NET 8 is still actively supported (as expected in a LTS version), so I will keep using it until .NET 10 arrives.

@jodydonetti I have found some other packages which depends on the "correct" Microsoft packages versions:

That is from NSwag.AspNetCore. Here are the csproj and the nuspec, as you can see, for Microsoft.Extensions.ApiDescription.Server it depends on a 6 version, I assume because that's the minimum valid, and for Microsoft.Extensions.FileProviders.Embedded it depends on the version of the .NET target, so 8.* for .NET 8 and 9.* for .NET 9.

[jodydonetti]

Hi @andriibratanin

In my case NU1605 error is related to Microsoft.Extensions.DependencyInjection.Abstractions package which I have to reference directly due to code requirements

Help me understand one detail please: your requirements are to "reference Microsoft.Extensions.DependencyInjection.Abstractions" or to "reference Microsoft.Extensions.DependencyInjection.Abstractions v8" ?

The thing I'm not understanding is why it's not possible to update those references to the related v9 versions, since they are all backward compatible and would not create any issue (at least to the best of my knowledge, in case that's not the case let me know).

As an additional info: I know some are using FusionCache v2 on the very old .NET Framework v4.X, and even they don't have any problem at all, so I'm trying to understand where exactly is the problem, so I may get to a solution.

[alexaka1]

For clarity on .NET major releases:

The quality of all releases are exactly the same, the only difference is the length of support.

https://dotnet.microsoft.com/en-us/platform/support/policy

[alexaka1]

As for package versioning, I think we should look at other community packages instead.
Serilog recently upgraded to .Net 9, even though they support net462.
Refit also targets 8.x packages on TFMs that don't include System.Text.Json
To my suprise AKKA is stuck at .Net 6, so if you use it now, you use the netstandard2.0 TFM variant, so you get System.Threading.Channels at a 6.0 version, but your project can still manually 'upgrade' to 9.0.0.
You would be hard pressed to argue that OpenTelemetry stopped supporting .Net 8. They also target .Net 9 even though they support as low as net462.
MediatR, net6 TFM, 8.x package
Polly does both. It requires 8.x for anything lower than net9.0. Which means when you target net6.0, you must upgrade to 8.x.
Same for MassTransit. Actually even more interesting I think this branch causes .netstand2.0 to use System.Text.Json:9.0.0. Meaning if you use .net6.0, tough luck, gotta upgrade to .Net 9, which is misleading. You don't upgrade your TFM, just the nuget version.

So it is actually quite common to depend on the latest major version of a package, even if you multi TFM to older versions.