Разрешение / использование нескольких версий сборок из сторонних зависимостей - PullRequest
5 голосов
/ 30 марта 2012

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

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

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

Ссылка на две разные версии log4net в одном решении

Использование разных версий одной и той же сборки в одной папке

Сторонние библиотеки ссылаются на разные версии log4net.dll

Как работать с несколькими версиями зависимостей?

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

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

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

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

1 Ответ

1 голос
/ 01 апреля 2012

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

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

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

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

...