Upgrade version of some packages needing system.memory

[jcaspes]

so they use the same version (4:0:1:2) than System.Hashing.IO

System.Hashing.IO can not be downgraded for old .net because first version with XxHash3 use system.memory 4:0:1:2

see issue #3055 for more informations

My tests from a simple .net 4.8 cmmandline thant include Stackexchange.redis seem to be OK without needing to add ugly runtime assemblyBinding in .config file

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.

[mgravell]

For clarity, can I ask: were you seeing a specific issue that this addresses? Note that we've already applied this in the v3 branch (currently in preview, see here), so I'm torn between this vs "leave v2 alone". Also, since .NET 10 is GA and LTS, I wonder if the SDK 10 packages may be preferable to SDK 9.

[jcaspes]

Hello! yes you can ask ;-)

I've explained the "problem" here: #3055

A simple app in .Net 4.8 including stackexchange.redis last release stop with exception with an Asssembly reference error from System.IO.Pipelines.dll coming from you unofficial io.pipeline package 2.2.8.

System.IO.Pipelines.dll need system.memory 4:0:1:1, but the one delivered is 4:0:1:2 due to System.IO.Hashing.dll.

At our side, we have a lot of commandlines that include our own redis dll including stackexchange.redis and can not run due to this.

A solution can be for us to add app.config to all these cmdlines with an assemblyBinding redirection to 4:0:1:2, but it's not a very good solution.

Not sure that the SDK 10 for .net 10 will be usable for our projects in .net 4.8 that we can't migrate to .net 10 for now :-(

[jcaspes]

A simple .net framework 4.8 program like in this screenshot + no .config file

reproduce the problem easily.

returning to version 2.9.32 in same project run perfectly ;-)

[mgravell]

Out of curiosity only, and purely a "if you have tim we" convenience (I don't expect you to update to a preview): if you have time to try the pre-release V3 build, is that "clean"?

[jcaspes]

here a simple project to reproduce.

StackExchange.test.net.4.8.zip

when building the binding problem is visible:

[jcaspes]

Out of curiosity only, and purely a "if you have tim we" convenience (I don't expect you to update to a preview): if you have time to try the pre-release V3 build, is that "clean"?

Hum, why not, i can try this. I can build this v3 branch and copy/past binaries to try it, but it will be tomorrow, i'm out of office now ;-)

[NickCraver]

Your issue looks to be some version pinning of transitive dependencies - we should definitely not update SE.Redis here.

[jcaspes]

Hello, it seem a problem because of a mix of microsoft sdk versions in packages used by SE.Redis by recent add of System.IO.Hashing from the SDK 9.
So now, SE.Redis on .net 4.x can not work any more alone without a bindingredirect, I think that's sad.

What is the reel reason to not update, Are you worried about performance issues or anything else?

[mgravell]

we should definitely not update SE.Redis here.

@NickCraver if we are taking the dep via "hashing", I'm fine with formalizing it

[NickCraver]

@mgravell To clarify: I mean we shouldn't bump all the package versions, no objections to hashing specifically with minimal pain.

@jcaspes To answer your question:

What is the reel reason to not update, Are you worried about performance issues or anything else?

Because it causes a lot of pain, and breaks people. It breaks more people, for no reason. What we have in your case is a misunderstanding of what the problem is. Binding redirects are a fundamental part of .NET Framework and they're generated by default. Otherwise think about it: every package in the world would have to agree at all times. That's just never the case. Fixing you breaks other people - none of that is a win. We go with maximum compatibility and lowest requirements always - everything else is per-application to redirect and has been that way for decades.

[jcaspes]

@NickCraver, first thank to read my messages :-).

I totally get this whole redirection thing—I’ve been working on a lot of C# projects for a long time and run into these issues all the time.

But in this case, as I show with the simple little project above, redirection is mandatory because otherwise SE.Redis doesn’t work. The issue is internal to SE.Redis; it can’t function correctly natively… I find that weird, I've never encountered this problem with a NuGet package.

Also, for your information, I'm working on this "issue" because we have, for example, a project in Managed C++/CLI DLL, and in this case, redirects aren't generated automatically or detected by MSBuild; so the problem have been detected only at runtime (thanks to the automated tests ;-) ), but it's dangerous.

Also, this PR doesn’t bump all packages, but only the minimum necessary to ensure that SE.Redis is clean with everyone linking to System.Memory 4:0:1:2

[jcaspes]

@mgravell, today i found time to test the V3 with the Managed C++/CLI cmdline project in .net framework 4.8 we have.

The test was successful, no binding redirection to define ;-).
This CL do not do complex things but some HSET/HGET but worked perfectly.

I will test this V3 with our more complex project that is a web app in asp .net 4.8 also.

Thank for your work !