Home/ Questions/Q 7725487
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-01T04:56:59+00:00

In my project, I have a problem with its dependency hierarchy. I use a

  • 0

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: dependency tree

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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0