search

ZiggyCreatures / FusionCache

FusionCache is an easy to use, fast and robust hybrid cache with advanced resiliency features.
MIT License
1.57k stars 84 forks source link

Minimal package version of Caching.Memory for .Net 7.0 #260

Open R0boC0p opened 1 month ago

R0boC0p commented 1 month ago

I am currently using FusionCache in version 0.24.0 on my .Net project that targets .Net 7.0. I'd like to bring FusionCache forward to 1.2.0 which I currently cannot do, as the minimal required version for Microsoft.Extensions.Caching.Memory is 8.0.0. This leads to many version conflicts on my end when resolving the Nuget-Packages.

Unfortunately I cannot move onto .Net 8.0 either. Contrary on the Nuget.org page, it says that the package should be compatible with .Net 7.0. Is this due to the 0.x.x versions of Fusion cache?

Could the Project define a lower minimal version like 6 or 7.0.0 ?

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

Thanks for your time and consideration.

jodydonetti commented 1 month ago

Hi @R0boC0p and thanks for using FusionCache.

The Microsoft.Extensions.Caching.Memory package does not force the upgrade to .net 8, as it has a broad support, see here.

Did I miss something?

R0boC0p commented 1 month ago

Hi @jodydonetti, I put it the wrong way. It does not enforce upgrading to .Net 8. It's that I am consuming company internal Nugets that come with the Caching.Memory in Version 7.0.0. If I would want to use FusionCache in the latest version, it would mean that I have to update all Projects and all Dependencies correspondingly (daunting task) - and probably switch to .Net 8 during this process.

I checked the minimal version on FusionCache and was mere wondering, why you use a min version of Microsoft.Extensions.Caching.Memory that is 8.x.x. Is it due to a specific feature set introduced in the version 8?

Thanks for clarifying.

jodydonetti commented 1 month ago

Hi, no need (at least in theory)!

If package A depends on Microsoft.Extensions.Caching.Memory v7 directly (or transitively) and on FusionCache v1.0 which in turn depends on Microsoft.Extensions.Caching.Memory v8, package A will just use Microsoft.Extensions.Caching.Memory v8 without having to re-target and recompile, since a newer version can be used in place of an older one (and Microsoft 99.999% of the times ensures it does not break anything).

I do that all the times without problems.

Can you try and see if it works? Thanks!

R0boC0p commented 1 month ago

My company is using central package versioning for all nugets I consume in my project, which does not (in .Net 7) support floating or version ranges. Microsoft packages for cache, dependency-injection, options etc are all pinned to a 7.xx version. This might be the reason why I cannot resolve the version conflicts, and is a current limitation of CPV in .Net7. I think if my companies packages could use minimal package versions for at least the nugets, this would probably solve my issue.

Thanks!

jodydonetti commented 1 month ago

My company is using central package versioning for all nugets I consume in my project, which does not (in .Net 7) support floating or version ranges. Microsoft packages for cache, dependency-injection, options etc are all pinned to a 7.xx version. This might be the reason why I cannot resolve the version conflicts, and is a current limitation of CPV in .Net7.

Ah, I see now. I haven't considered such scenario when I upgraded the deps in preparation for the v1.0.

I think if my companies packages could use minimal package versions for at least the nugets, this would probably solve my issue.

Let me know if it worked, you are the first one to highlight this issue, and I'd like to help but also I'd like to keep a minimum version for the deps for everyone else, so... let me know!