Как скомпилировать библиотеку без блокировки в указанной версии DLL

#c# #.net #dependencies #nuget #build-dependencies

Вопрос:

Я разрабатываю библиотеку классов с открытым исходным кодом (MySqlBackup.NET), который он может работать с 3 дополнительными зависимостями, разработанными разными разработчиками, но все они имеют одинаковые пространство имен Тип MySqlCommand .

  • MySQL.DATA.dll
  • Devart.Data.MySql.dll
  • MySqlConnector.dll

Каждый раз, когда я выпускаю пакет nuget, мне нужно 3 раза компилировать отдельно с его конкретными зависимостями.

Есть ли способ скомпилировать библиотеку, которая работает без необходимости привязки (блокировки) конкретной целевой зависимости? Что он будет работать, если какая-либо из зависимых библиотек dll, содержащих необходимые пространство имен тип существует.

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

Как скомпилировать библиотеку классов, которая будет игнорировать номер версии зависимостей?

Комментарии:

1. Похоже, вы ищете заглушки API и подключаемую архитектуру.

2. MySqlCommand это тип, а не пространство имен, нет?

3. @MarcGravell, ты прав. поправляю…

Ответ №1:

Короткий ответ: нет, не так, как вы хотите; идентификатор типа (в IL) определяется сборкой и полным именем типа — вы не можете просто сказать «это имя типа, но мне все равно, откуда».

Вы, пожалуй, могли зависеть DbCommand (или в более общем плане: API В System.Data.Common ), а не какого-либо конкретного поставщика видах; обычно этого достаточно для большинства ADO.NET работы , если вам позарез нужно трогать поставщика API, в этом случае вам может понадобиться использовать некоторые формы отражения во время выполнения кода (например: щеголеватый использует оптимизированные отражение настроить Oracle для BindByName поведения, когда он находит его). Обратите внимание, что ADO.NET также есть заводская модель поставщика, хотя работать с ней не очень весело.

Другой подход состоит в том, чтобы иметь основную библиотеку, содержащую общую/общую логику, и 3 вспомогательные библиотеки, которые все зависят от этой основной библиотеки и содержат аспекты, зависящие от поставщика (очевидно, что каждая вспомогательная библиотека также будет ссылаться на пакет для одного из API, зависящих от поставщика). Из-за того, как работают временные зависимости, вашему среднему потребителю тогда просто понадобится один пакет-например, ссылка на соответствующий пакет для конкретного поставщика MySqlBackup.Devart (назвать сложно!).