Resolving/using multiple assembly versions from 3rd party dependencies

Question

In my project, I have a problem with its dependency hierarchy. I use a library (WriteableBitmapExtensions) in my code, and I have another 3rd party library which also uses WriteableBitmapExtensions. Only the other library is strongly tied to a specific, older version, and my code needs the functionality in its latest version.

Here's a depiction of the dependencies:

There are similar questions & solutions but they resolve it with assembly binding at runtime via a config file, but I don't think this is compatible for a Silverlight application.

Referencing 2 different versions of log4net in the same solution

Using different versions of the same assembly in the same folder

3rd party libraries refer to different versions of log4net.dll

How to deal with multiple versions of dependencies?

So is there a way to resolve these different versions of assembly dependencies in a Silverlight context? If there isn't, I figure my options are:

1) Most likely I can convince the vendor of the 3rd party library to update to use the latest version of WriteableBitmapExtensions, but I'd prefer to not be dependent on them keeping it up-to-date. Especially since the WriteableBitmapExtensions project is still being updated and we're often taking advantage of their new features.

2) Since WriteableBitmapExtensions is open-source, I suppose I can recompile its source as a new assembly "MyWriteableBitmapExtensions" and use that in my source code. But I'll run into this issue again if two 3rd party libraries reference different versions of WriteableBitmapExtensions.

I suspect I'll be going with option 2, but I'd like to know if there's a better way of doing this (like the runtime assembly binding in the other questions) before I commit/refactor. Thanks!

Shed

Answer 1

As I've said in my comment, Option 1 should be readily available because "v1" is actually a "pre beta" version.

If there is a delay in the 3rd party vendor releasing a build using a non-beta version, your Option 2 is your next option. Just make sure you use a completely new identity for your build of MyWriteableBitmapExtensions: specifically use a different AssemblyName, FileName, Strong Name Signature and any GUIDs used for identity, including for COM.

If you didn't need the new functionality or if the v2 was backward compatible with v1, assembly binding would still be the preferable option -- I haven't confirmed if this is available with Silverlight, but I'd be surprised if it wasn't though I now agree true assembly binding is probably unavailable in Silverlight because the whole System.Configuration namespace is missing from Silverlight (except for two enumerations in System.Configuration.Assemblies).

Nevertheless, another option is to adjust the latest source code so that it does produce something that is backward compatible to v1, perhaps breaking the v2 features if you have to -- in such a way the v2 features can still be used, just with a recompile, now with the original identity (AssemblyName, FileName, Strong Name Signature, etc.). Then you should be able to use the one assembly for both scenarios again.

Rotz

I only actually looked at the WriteableBitmapExtensions project after writing this answer and I now realise what you referred to as v1 is actually almost definitely a pre-beta version, seeing as the latest is v1 beta. So option (1) becomes more of an option -- the 3rd party vendor should be quite happy to re-release with a non-beta version when it becomes available. – Rotz

I have now edited this answer again as it looks like Silverlight doesn't support assembly binding :-( – Rotz

Yeah, that was initial take on it too. I do expect this particular vendor would update; they're pretty good that way. I do have concerns about other libraries in general and was wondering if there was a full/proper solution (like assembly binding) especially since the whole "open-source, recompile" option might not always be available, but it looks like there might not be. Thanks for the note to update the identity GUIDs & Strong Name, I might have overlooked those. – Shed