Update to System.Reactive v3.0 for improved compatibility with other extensions

[kzu]

The currently shipping extension distributes System.Reactive.*.dll version 2.2.5.

Updating to 3.0.0 will make it compatible with the version shipped by Xamarin.

[grokys]

I actually tried to update this recently, but 3.0.0 seemed to change behavior in a way which broke us. Hopefully I can look further into this after the next release and complete the upgrade.

[kzu]

Here's an example of how it breaks: https://developercommunity.visualstudio.com/content/problem/287648/xamarin-android-and-ios-projects-will-not-load-aft.html

[grokys]

Thanks @kzu - we've got a release coming up next Monday, hopefully once that's out I can try upgrading again.

However, what I don't understand is why these two packages are clashing. They're both strong-name signed so from what I understood they should be treated as two separate libraries within VS. Is that not the case? Does this mean that all VS extensions will have to use the same version of System.Reactive?

[kzu]

VS does not load multiple versions of the same assembly automagically. First one wins, basically, and subsequent ones get a runtime error from type mismatches. The only way to avoid that is binding redirects, which can then collide since we'd redirect to 3.0 and you would to 2.x. And that point, I think whoever loads first wins, and you are back to mismatches. This is more or less the same reason why it's strongly encouraged that everyone uses the VS-provided version of Newtonsoft.Json (currently v9), instead of providing another version with your extension.

The only way to workaround the issue is to load sufficiently early (a general no-no), attach to the assembly resolve event and detect that your provided version is being resolved and provide your extension local path to the assembly. That's something we'd rather not do.

[shana]

@kzu GitHub for VS references a custom signed version of Rx that we build and ship. The nuget package is in the lib/ dir if you want to take a look at it. The reason we have a custom built and custom signed package is precisely so that the runtime resolver doesn't get confused about different versions available in the system and tries to redirect things somewhere else - essentially, they're different assemblies, and cannot clash.

For background, we do this because Rx has two ABI-incompatible DLLs that have the same version and signature (one for the .net 4.0 profile and one for 4.5 iirc), and Xamarin shipped with one while we shipped with the other. Depending on who loads first, we might end up with MethodMissing exceptions all over the place because the runtime resolver naturally considers them to be the same. Using our own custom signed assembly guarantees that there are never clashes, no matter who ships what in the environment - we load ours, everyone else loads theirs.

I'm not sure how your Rx version is possibly clashing with ours in this situation. Do you have a repro for this? A fusion log will probably be helpful in figuring out what is actually clashing, what with MEF and all.

[kzu]

custom signed package

gotcha. Missed that part. If the public key token is different, all should be good.

[clairernovotny]

@shana The ABI issue was in 2.x and resolved since then. The latest releases, 4.x are ABI compatible. Further, the tfm's have been reduced. There's net46, netstandard2.0 and uap. The NET 4.6 version is a full superset of the netstandard version.

There should not be a need for a custom signed version of Rx for this.