Поддержание общей библиотеки среди сотен небольших приложений

Question

У меня возник вопрос о создании общей библиотеки для очень большого числа небольших приложений. Недавно я присоединился к команде разработчиков. Мы собираемся расширить до 3. У нас есть более 200 приложений, которые мы поддерживаем. Все приложения поддерживают наши операции, и все они находятся в проектах развития дома.

Все эти приложения ссылаются на множество сторонних зависимостей, таких как dapper, nlog и т. Д. Но ни одна ссылка не используется в домашней библиотеке.

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

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

Моя первоначальная мысль заключалась в том, чтобы все 200 приложений ссылались на одну и ту же версию библиотек, которые автоматически перестраивались с помощью сборки CI при изменении новой ее зависимостей (библиотек), но из того, что мне сказали это слишком рискованно и не поддерживается TFS.

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

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

---

Редактировать, чтобы уточнить от потенциала дублирующий вопрос

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

Answer 1

Вы, вероятно, поддерживаете сторонние зависимости, такие как NLog, с помощью NuGet.

Почему бы не использовать NuGet для вашей внутренней библиотеки? Вы можете настроить фид NuGet с разумными усилиями.

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

В этих сценариях вы можете настроить настраиваемый фид NuGet, и вы можете настроить Visual Studio на предложение этого фида вместо или в дополнение к официальному каналу. Канал может быть локальным (папка на локальном компьютере или сетевая папка) или удаленный (интрасеть или интернет-URL).

Источник: docs.nuget.org

В зависимости от уровня комфортности размещения вашего кода, скомпилированного во внешнем центре обработки данных, существует также целый ряд поставщиков услуг NuGet перечисленных в той же ссылке.