Устранение/использование нескольких версий сборки из сторонних зависимостей

Question

В моем проекте у меня проблема с иерархией зависимостей. Я использую библиотеку (WriteableBitmapExtensions) в своем коде, и у меня есть другая сторонняя библиотека, которая также использует WriteableBitmapExtensions. Только другая библиотека сильно привязана к определенной, более старой версии, и мой код нуждается в функциональности в своей последней версии.

Вот описание зависимостей:

Есть подобные вопросы & решения, но они решают его сборочный связывания во время выполнения с помощью конфигурационного файла, но я не думаю, что это совместимо для Silverlight приложения.

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?

Так есть ли способ, чтобы решить эти различные варианты зависимостей сборки в Silverlight контексте? Если это не так, я считаю, что мои варианты:

1) Скорее всего, я могу убедить поставщика сторонней библиотеки обновить, чтобы использовать последнюю версию WriteableBitmapExtensions, но я бы предпочел не зависеть от они сохраняют актуальность. Тем более, что проект WriteableBitmapExtensions по-прежнему обновляется, и мы часто используем их новые функции.

2) Поскольку WriteableBitmapExtensions является открытым исходным кодом, я полагаю, что я могу перекомпилировать его источник как новую сборку «MyWriteableBitmapExtensions» и использовать ее в своем исходном коде. Но я снова столкнусь с этой проблемой, если две сторонние библиотеки ссылаются на разные версии WriteableBitmapExtensions.

Я подозреваю, что у меня будет вариант 2, но я хотел бы знать, есть ли лучший способ сделать это (например, привязать сборку времени выполнения в других вопросах), прежде чем я завершу/рефакторинг. Благодаря!

Answer 1

Как я уже сказал в своем комментарии, вариант 1 должен быть легко доступен, потому что «v1» на самом деле является версией «pre beta».

Если у стороннего поставщика есть отсрочка, выпускающая сборку с использованием не бета-версии, ваш вариант 2 является вашим следующим вариантом. Просто убедитесь, что вы используете совершенно новую идентификацию для своей сборки MyWriteableBitmapExtensions: в частности, используйте другое AssemblyName, FileName, Strong Name Signature и любые GUID, используемые для идентификации, в том числе для COM.

Если вам не нужна новая функциональность или если v2 был обратно совместим с v1, сборка привязки по-прежнему была бы предпочтительной опцией - Я не подтвердил, доступен ли это в Silverlight, но я бы если бы не было, хотя я согласен с тем, что истинная привязка сборки, вероятно, недоступна в Silverlight, потому что в Silverlight отсутствует полное пространство имен System.Configuration (за исключением двух перечислений в System.Configuration.Assemblies).

Тем не менее, другой вариант заключается в том, чтобы отрегулировать последний исходный код так, чтобы он сделал, что-то, что обратно совместимо с v1, возможно, нарушая функции v2, если вам нужно - таким образом, функции v2 могут все еще используйте только с перекомпиляцией, теперь с оригинальным идентификатором (AssemblyName, FileName, Strong Name Signature и т. д.).Затем вы сможете снова использовать одну сборку для обоих сценариев.