Пакет Nuget, поддерживающий несколько версий их зависимостей

#entity-framework #nuget #entity-framework-6

#entity-framework #nuget #entity-framework-6

Вопрос:

Я ищу некоторый опыт или мысли по следующей проблеме.

У меня есть пакет Nuget (EntityFrameworkExtras 1.2.0), который размещен в основном канале Nuget.

Этот пакет зависит от EntityFramework. Все было в порядке, пока не была выпущена EntityFramework 6.

Изменение в коде EntityFramework означает, что мой пакет больше не работает с EntityFramework 6 и более поздними версиями.

Я пытаюсь рассмотреть, как лучше всего справиться с этой проблемой, я предвижу два варианта:

1) Поддерживать 2 версии пакета

Итак, у меня была бы одна версия пакета, которая скомпилирована с EntityFramework 5.0.0, а .nuspec будет указывать, что он зависит от EntityFramework [0.0.0 — 5.0.0]

Я бы представил новый пакет под названием EntityFrameworkExtras (ef6). Этот пакет будет скомпилирован в EntityFramework 6.0.0, а в .nuspec будет указано, что он зависит от EntityFramework [6.0.0 > = *]

2) Иметь новую версию текущего пакета, который будет поддерживать EntityFramework 6.0

таким образом, текущая версия будет поддерживать EntityFramework 5.0.0 и меньше, и я бы добавил новую версию пакета (версия 2.0.0), которая будет зависеть от EntityFramework 6.0.0 [6.0.0 > = *]

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

1. Вы видите, что используются оба этих параметра. Если вы посмотрите на пакет, подобный Glimpse, вы увидите, что пакет называется Glimpse.EF5 , и т.д. Glimpse.EF6

2. Я буду считать, что проголосовал за 1) 🙂

3. Просто просматривая списки пакетов в Nuget, люди, похоже, предпочитают вариант 1)

Ответ №1:

В конце концов я выбрал вариант 1). Я считаю, что это более простой вариант для пользователя пакетов, потому что ясно, каковы зависимости каждого из пакетов.

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

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