Dependancy conflicts in Microsoft packages between redis and redis.strongname

[Herostwist]

I have an asp net core app with a few Microsoft packages.

Microsoft.AspNetCore.DataProtection.StackExchangeRedis depends on StackExchange.Redis
Microsoft.Extensions.Caching.Redis depends on StackExchange.Redis.StrongName

Whenever I try and reference anything in the StackExchange.Redis namespace it causes a CS0433 error.

Can you release a version of Microsoft.Extensions.Caching.Redis referencing StackExchange.Redis >= 2.0 so it plays nice with other Microsoft packages. Even a prerelease would be appreciated.

Thanks.

[Tratcher]

aspnet/Announcements#322
Microsoft.Extensions.Caching.Redis was replaced by Microsoft.Extensions.Caching.StackExchangeRedis

[Herostwist]

Super, that is good to know. A note to that affect would be very handy in the description on nuget - https://www.nuget.org/packages/Microsoft.Extensions.Caching.Redis

[analogrelay]

We'll use the deprecation feature in NuGet to do this when it's available: NuGet/Home#2867

Updating the description on NuGet requires shipping an entirely new version which seems unhelpful as it will make users think a new version is available when it's just a description update.

[Herostwist]

Hmm, I see your dilemma. A depreciation feature is sorely needed on NuGet, especially considering if you search NuGet for "Microsoft Caching Redis" the depreciated Microsoft.Extensions.Caching.Redis comes up ahead of Microsoft.Extensions.Caching.StackExchangeRedis in the search results. I wonder how many people like myself have installed it with no idea that it has been replaced.

[inkel]

I've a similar problem. My project was already using StackExchange.Redis.StrongName, and when I added Microsoft.Extensions.Caching.StackExchangeRedis this is what I get when trying to dotnet build:

Redacted/Foo.cs(8,9): error CS0433: The type 'ConnectionMultiplexer' exists in both 'StackExchange.Redis.StrongName, Version=1.2.6.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis, Version=2.0.0.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' [/Users/inkel/foo/bar/Quux.csproj]
Redacted/Foo.cs(9,9): error CS0433: The type 'IDatabase' exists in both 'StackExchange.Redis.StrongName, Version=1.2.6.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis, Version=2.0.0.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' [/Users/inkel/foo/bar/Quux.csproj]
Redacted/Quux.cs(8,17): error CS0433: The type 'IDatabase' exists in both 'StackExchange.Redis.StrongName, Version=1.2.6.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis, Version=2.0.0.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' [/Users/inkel/foo/bar/Quux.csproj]
Redacted/Bar.cs(28,16): error CS0433: The type 'ConnectionMultiplexer' exists in both 'StackExchange.Redis.StrongName, Version=1.2.6.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis, Version=2.0.0.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' [/Users/inkel/foo/bar/Quux.csproj]
Redacted/Bar.cs(33,16): error CS0433: The type 'IDatabase' exists in both 'StackExchange.Redis.StrongName, Version=1.2.6.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis, Version=2.0.0.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' [/Users/inkel/foo/bar/Quux.csproj]
Redacted/Bar.cs(9,31): error CS0433: The type 'ConnectionMultiplexer' exists in both 'StackExchange.Redis.StrongName, Version=1.2.6.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' and 'StackExchange.Redis, Version=2.0.0.0, Culture=neutral, PublicKeyToken=c219ff1ca8c2ce46' [/Users/inkel/foo/bar/Quux.csproj]

Any ideas how can I workaround this?

[analogrelay]

If you are able to update your usage to the newer StackExchange.Redis package which is strong-named, that is ideal. It will avoid the conflict.

If you can't update that, you should stick with Microsoft.Extensions.Caching.Redis

[inkel]

I wasn't using Microsoft.Extensions.Caching.Redis to start with, and it was my understanding that, according to @Tratcher comment, that the package was replaced by Microsoft.Extensions.Caching.StackExchangeRedis. I'd rather not stick with deprecated versions.

One possible solution that I've found was to add the following to my .csproj:

  <Target Name="ChangeAliasesOfStrongNameAssemblies" BeforeTargets="FindReferenceAssembliesForReferences;ResolveReferences">
    <ItemGroup>
      <ReferencePath Condition="'%(FileName)' == 'StackExchange.Redis.StrongName'">
        <Aliases>signed</Aliases>
      </ReferencePath>
    </ItemGroup>
  </Target>

Although that seems quite hacky, it does the trick for now.

[analogrelay]

I'd rather not stick with deprecated versions.

The same would generally apply to StackExchange.Redis.StrongName then. It's not deprecated per-se, but the 2.x version is in a different package (StackExchange.Redis, see the StackExchange.Redis release notes for more), so if you're going fix this conflict, I'd suggest doing it by updating to StackExchange.Redis 2.x. The 2.x version of StackExchange.Redis is strong-named, so if you were avoiding that package primarily due to it not being strong-named, that has changed in StackExchange.Redis 2.x.

In general, the problem is crossing these two streams. In ASP.NET Core 2.1 and 2.2, the Microsoft.Extensions.Caching.Redis and Microsoft.Extensions.Caching.StackExchangeRedis packages are basically the same, they only differ on which Redis package they depend upon. ASP.NET Core 3.0 will only support Microsoft.Extensions.Caching.StackExchangeRedis so if you are planning to migrate soon, that's something to consider.

So it's a matter of choice, you have three options:

• Unify on Microsoft.Extensions.Caching.Redis and StackExchange.Redis.StrongName, though you will be limited to stay on ASP.NET Core 2.2 or earlier and StackExchange.Redis 1.x
• Unify on Microsoft.Extensions.Caching.StackExchangeRedis and StackExchange.Redis, which will keep you on the latest for both the caching component and the Redis client
• Use both via the Alias workaround you described above. As long as you don't need to transfer objects from one version to the other, this is fine. The runtime will load both StackExchange.Redis and StackExchange.Redis.StrongName in memory and use them.

[inkel]

Thank you so much, @anurse ! This is a very detailed and useful answer. I think I'll go with the second option, I need to ask my team first, though. I'll let you know how it goes.

[KeithHenry]

It looks like Microsoft.AspNetCore.All points to Microsoft.Extensions.Caching.Redis, so you can't use it with StackExchange.Redis.

@anurse does that mean we need to expand out all the dependencies in Microsoft.AspNetCore.All?

Should the readme be updated to reflect that users shouldn't follow https://github.com/aspnet/Extensions#get-started as that adds Microsoft.AspNetCore.All?

[inkel]

Hi everyone, updates on this: we've replaced the dependency on Microsoft.AspNetCore.All with Microsoft.AspNetCore.App, and that worked fine for solving the issue mentioned with StackExcange.Redis.

I did have to update an unrelated dependency on Microsoft.Extensions.Configuration.Binder due to some down-versioning of said dependency. I've updated the dependency to 2.2.4 and now all warnings and errors disappeared.

Thanks for all the pointers!

[udlose]

aspnet/Announcements#322
Microsoft.Extensions.Caching.Redis was replaced by Microsoft.Extensions.Caching.StackExchangeRedis

Unless you've subscribed to the 'Announcements' (which I have now), the average developer would not know that they should be moving to the new package.....maybe the .NET team should consider marking the methods in Microsoft.Extensions.Caching.Redis as Obsolete via Warnings? There should be an easier way to know this upgrade is recommended than having to Google for package conflicts and come across this Issue to find the solution.

[ghost]

As part of the migration of components from dotnet/extensions to dotnet/runtime (aspnet/Announcements#411) we will be bulk closing some of the older issues. If you are still interested in having this issue addressed, just comment and the issue will be automatically reactivated (even if you aren't the author). When you do that, I'll page the team to come take a look. If you've moved on or workaround the issue and no longer need this change, just ignore this and the issue will be closed in 7 days.

If you know that the issue affects a package that has moved to a different repo, please consider re-opening the issue in that repo. If you're unsure, that's OK, someone from the team can help!