Repository navigation
System.Memory binding #3055
Description
Hello @mgravell
After upgrading to Release version 2.12.14, a binding error appear when including StackExchange.Redis in a .net 4.8 project.
Indeed, by looking dependencies, we can see that two versions of System.Memory is now used:
The new reference to System.IO.Hashing in this commit (94e0090 and c979c6b), have introduced system.memory V 4:0:1:2 but System.IO.pipeline.dll 2.2.8 from your unoficial pipeline package reference system.memory 4:0:1:1.
I made a PR that fix this issue, your pipeline package version 2.2.16 fix the dependency, but also needed to upgrade Microsoft.Bcl.AsyncInterfaces and Microsoft.Extensions.Logging.Abstractions
Activity
NickCraver commentedon Apr 14, 2026
You're in need of a proper binding redirect, these are generally generated for you automatically. The fix is never for every package to upgrade (that would require all package combinations in the world to agree).
This comes up often enough we made a post for it: https://nickcraver.com/blog/2020/02/11/binding-redirects/
jcaspes commentedon Apr 14, 2026
Yes, I know, but as I explained, we have a lot of tools that didn't have a .config file or a bindingredirect until now.
That's why I tried to figure out where the problem came from after upgrading StackExchange.Redis from 2.9.32 to 2.12.14 to avoid starting with redirect, to stay "clean" ;-).
Also i think that in this case it's not a "all package combinations in the world to agree" but just StackExchange.Redis that is not agree with it's own dependencies :-) like you can see in my screenshot in this issue first post or with the simple 4.8 project that only reference StackExchange.Redis 2.12.14 here : #3056 (comment)
And this is due to the recent inclusion of System.IO.Hashing of SDK 9 here 94e0090 so there is a mix of SDK versions.
mgravell commentedon Apr 16, 2026
(just for clarity: many of my thoughts are shown on the PR)
mgravell commentedon Jul 22, 2026
Thanks for the report. StackExchange.Redis 3.0 ships a substantial rewrite of the low-level IO core — a new RESPite-based stack that replaces
Pipelines.Sockets.Unofficialand the old backlog/write loop — and we're confident this issue is addressed by that work.Closing as resolved in 3.0. If you can still reproduce on 3.0.x, please comment and we'll reopen and investigate with fresh diagnostics.