Популярные библиотеки с открытым исходным кодом и конфликты ссылок

Мы используем log4net во всех наших (многих) внутренних приложениях. Обычно мы делаем то, что составляет развертывание xcopy. Для удобства разработчиков мы скомпилировали исходный код log4net в одну из наших основных библиотек.

Теперь это возвращается, чтобы укусить нас. Другие библиотеки с открытым исходным кодом (например, Topshelf ) ссылаются на log4net. Третьи (например, NServiceBus ) объединяют log4net в свои сборки. Обычно версии различаются.

Это общий вопрос; конкретные библиотеки - это просто примеры.

Есть несколько схожих вопросов:

• Определение манифеста обнаруженной сборки не соответствует ссылке на сборку
• .Net выбирает неверную версию сборки, на которую указывает ссылка
• Как устранить неоднозначность между моей проектной DLL и DLL в GAC?
• Конфликт ссылок на сторонние DLL, скомпилированные в .NET

Из различных решений (GAC, assemblyBinding, bindingRedirect и т. Д.) Что, вероятно, вызовет у нас меньше всего проблем в будущем? Мы можем изменить нашу основную библиотеку; мы просто не можем сделать ничего, что могло бы сломать существующую развернутую версию в полевых условиях. Обновление всех ссылок на наши проекты будет болезненным, поэтому мы хотим сделать это только один раз.

Обновление: Текущая версия абстрактного ведения журнала Topshelf, так что это больше не проблема с этой структурой.