MessagePack v2 causes TypeLoadExceptions in Microsoft.AspNetCore.SignalR.StackExchangeRedis

[paul-pz]

Microsoft.AspNetCore.SignalR.StackExchangeRedis breaks at runtime if MessagePack v2 is added. Might be worth constraining the nuget package until this fixed.

[jkotalik]

@paul-pz could you provide more details on this? What exception is thrown from the runtime? What version of StackExchangeRedis are you using?

cc @BrennanConroy @AArnott

[AArnott]

MessagePack v2 has many (by design) breaking API changes from v1. Given ASP.NET Core now only runs on .NET Core, which doesn't support loading two assembly versions with the same simple name at once, this means if SignalR compiles against MessagePack v1 then it's toxic for a web app to reference MessagePack v2 since only one will load and cause a failure in one use or the other.

[analogrelay]

We can look at updating to MessagePack v2 in a future major version. I'll put this in our queue to review for future planning.

Until then, @AArnott is correct, using MessagePack v2 is not compatible with SignalR.

I'll leave this open to track updating.

[tebeco]

Until then, @AArnott is correct, using MessagePack v2 is not compatible with SignalR.

arg :D, I was trying to attempt a PR to update MessagePack v2.0 since few day.
Since v1.x API tends to be allocation prone, i wanted to see if there was a way to update it here.

@anurse
I'm note sure what's not compatible for 3.1 here, as MessagePack 2.x targets both netocreapp2.1 and netstandard2.0

[AArnott]

It's not MessagePack v2 is incompatible with .NET Core, because it certainly is compatible.

The problem is that .NET Core by default will only load one version of a given assembly (whereas .NET Framework was perfectly willing to load multiple versions). So if you load MessagePack v2, then ASP.NET Core's Signal library can't load v1 and will get v2 instead. Since v1 and v2 have API breaking changes, this breaks SignalR.

If you are careful with your assembly load contexts, you can get .NET Core to load your MessagePack v2 code in an isolated assembly load context so that it doesn't disrupt SignalR's loading of MessagePack v1 in another assembly load context. This may work well if your messagepack code is fairly isolated.

[tebeco]

Any tips if the the submitted PR should do the trick if it's not API breaking change or "new feature" ?
It's changing a transitive, while the "bytes on the wire" should still be compatible for MessagePack itself regardless of the version

(Once i understand what i did wrong for the files from the SubModule -_-)

[paul-pz]

@AArnott, yes that's correct - I'm using MessagePack directly. I upgraded to V2 via nuget. What I would have expected is that the upgrade should have failed because the SignalR Redis package should have an upper constraint < 2.0.0 (since its obviously incompatible). Instead it succeeds, builds and fails at runtime.

[tebeco]

I will add it to the current PR on master
i'll see if i can also do it on release/3.1

[analogrelay]

What I would have expected is that the upgrade should have failed because the SignalR Redis package should have an upper constraint < 2.0.0 (since its obviously incompatible)

That wasn't known at the time of release. We generally don't include upper bounds in our packages because they must be determined at the time of release and we do not know what the upper bound is at that time. Adding a upper bound means that even when a compatible release is made, it is not possible for a user to accept the update. Whereas, without an upper bound, if the release is compatible, the user can update. This is a general policy in ASP.NET Core though and it isn't really a good idea to discuss it in this thread. Let's stay focused on the task at hand: updating the packages to support MessagePack 2.0

I will add it to the current PR on master
i'll see if i can also do it on release/3.1

FYI @tebeco we don't take major version updates to dependencies in servicing releases so there's no point in a PR to release/3.1. We wouldn't be able to accept it as it would break existing customers who may have been using the previous MessagePack 1.x APIs in their application. Also, API changes cannot be done in servicing releases. Feel free to make a PR to master (it sounds like you've already done so, I haven't caught up on notifications yet).

[analogrelay]

Any tips if the the submitted PR should do the trick if it's not API breaking change or "new feature" ?
It's changing a transitive

Yes, this is considered a breaking change. Users may have been getting MessagePack through our dependency and may have code using the 1.x APIs. We cannot break them in a non-major release and must consider a breaking change update to transitive dependencies as a breaking change ourselves.