Настройка
Для наших приложений и утилит мы пытаемся нормализовать все наши (с открытым исходным кодом) библиотечные зависимости по всем инструментам к одной и той же версии;мы постоянно создаем все инструменты, чтобы убедиться, что все работает.
Проблема
Бывает, что мы должны использовать сторонние сборки библиотек .NET с открытым исходным кодом. Некоторые из этих сборок имеют свою собственную транзитивную зависимость от компонентов с открытым исходным кодом. Если мы используем один и тот же компонент с открытым исходным кодом, есть вероятность, что мы используем версию, отличную от зависимости с закрытым исходным кодом, и поэтому мы получаем конфликт.
Пример проблемы
Просто пример!
Наша сборка our_abc.dll использует стороннюю сборку their_xyz.dll с открытым исходным кодом, которая ссылается на Newtonsoft.Json.dll в другой версии, чем мы.
В этом случае типы json не используются на «поверхности API» между our_abc и its_xyz, что довольно часто встречается.
Решение?
Итак, чтомы бы хотели, чтобы наш код просто использовал сборку с открытым исходным кодом в нужной ему версии, а сторонняя сборка с закрытым исходным кодом, на которую мы ссылаемся, должна просто использовать их версию.
В идеале это должно быть достигнуто с помощьюкак можно меньше файлов конфигурации shenanigans. Использование GAC кажется довольно неуклюжим для некоторых развертываний.
Я читал о assemblyBinding, но я не уверен, что это правильный инструмент для работы, как нам кажетсядля этого потребуется вручную поддерживать все транзитивные зависимости в наших файлах app.config всех приложений, чтобы это работало:
Решение по ссылке делает это выглядит следующим образом. Учитывая эту ситуацию зависимости:
tool.exe -> my_abc.dll -> their_xyz.dll -> opensource.dll[v6]
\ ||
\ \/
\-> opensource.dll[v11]
... Я понимаю, что мог бы подготовить файл app.config для tool.exe, который указывает, где искать 2 (n)разные версии переходной зависимости.
Тем не менее, с точки зрения удобства обслуживания, было бы лучше, если бы я мог связать информацию вместе с their_xyz «пакетом», чтобы tool.exe не должен был знать о его транзитивных зависимостях. Это как-то возможно ?