Настройка библиотеки классов для распространения NuGet

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

В моем случае у меня будет фреймворк, который мы распространяем среди всех команд разработчиков в организации. Эта структура имеет «основную» библиотеку классов, а затем набор библиотек для конкретных технологий, таких как Acme.Web, Acme.Silverlight и так далее. Каждая из этих библиотек ссылается на «основную» сборку.

Я упаковал каждую из этих сборок в собственный пакет NuGet, включая «ядро», которое установлено как зависимость в других пакетах. Это связано с тем, что разработчики могут ссылаться только на «ядро» при создании библиотек классов, но также хотят использовать эти типы при создании веб-приложений и т. д.

Другая идея заключается в том, что я мог бы выпустить новую версию моей «основной» сборки, не требуя обновлений во всех других пакетах. Или я могу?

Представьте себе случай, когда у меня есть проект A, я добавляю пакет NuGet B, который зависит от пакета NuGet C, после чего пакет C обновляется. Можно ли распространять это обновление без пересборки, перепаковки и перепостинга пакета Б? Если да, нужно ли мне предпринять какие-либо шаги, чтобы убедиться в отсутствии проблем с версиями?


nuget nuget-package
person SonOfPirate    schedule 13.09.2011    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Похоже, вы задаете вопрос, учитывая следующий график зависимостей:

-> значит зависит от

B 1.0 -> C 1.0

Если произойдет обновление для C, скажем, C 1.1, вы хотите знать, можете ли вы опубликовать это обновление для C и позволить потребителям обновить его, не нарушая B.

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

Чтобы дать вам общее представление о том, как это будет работать. Скажем, вы в команде из 3 человек, вы, разработчик 1 и 2.

  1. Вы публикуете пакеты B 1.0 и C 1.0 в ленте вашей компании
  2. Разработчик 1 устанавливает B 1.0 и получает C 1.0
  3. Вы делаете небольшое исправление ошибки в C и называете его C 1.0.1 (поскольку он не ломается). Вы не обновляете B (это означает, что он говорит, что он зависит от C 1.0, а не от C 1.0.1).
  4. Разработчик 1 обновляет C до 1.0.1 и продолжает работать
  5. Разработчик 2 устанавливает B 1.0 и получает C 1.0.1 (поведение NuGet при разрешении зависимостей).

В приведенном выше сценарии вы изменили версию с C 1.0 на C 1.0.1, и вам не нужно было повторно публиковать B.

Теперь, если вы внесли огромное критическое изменение и увеличили версию до C 2.0, то, возможно, вы захотите рассмотреть возможность переупаковки B и увеличения номера версии, а также сделать эту версию B зависимой от C 2.0:

B 2.0 -> C 2.0
person davidfowl    schedule 15.09.2011
comment
У тебя получилось, это именно то, чего я хочу добиться. Превосходно! - person SonOfPirate; 16.09.2011