Лучшая практика для хранения и ссылки на библиотеки DLL?

Question

Часто разработчик из моей команды создает новый проект Visual Studio и ссылается на DLL где-нибудь на своем локальном компьютере (например, C: \ mydlls \ homersimpson \ test.dll). Затем, когда я получаю проект из репозитория управления исходным кодом, я не могу построить проект, потому что у меня нет ссылочной библиотеки DLL в точно таком же месте на моем компьютере.

Какова лучшая практика для хранения и ссылки на разделяемые библиотеки?

Answer 1

Я обычно создаю папку lib в своем проекте, куда я помещаю ссылочные библиотеки DLL. Затем я указываю ссылку на DLL в папке lib. Таким образом, каждый разработчик может построить проект после извлечения из системы контроля версий.

Если это проект, который был построен в доме, вы также можете добавить этот проект в свое решение.

Answer 2

Если сборка отсутствует в GAC, создайте каталог с именем зависимостей и добавьте туда все сборки. Папка и сборки будут добавлены в систему контроля версий. Правило состоит в том, что для любого проекта в системе контроля версий все, что требуется для сборки, - это оформить заказ и построить проект (или запустить какой-либо инструмент, который также включен в проект).

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

Для крупных решений с более чем 20 проектами это значительно облегчает жизнь!

Answer 3

В соответствии с рекомендациями, ваш репозиторий SC должен включать и обеспечивать для вас относительное расположение ссылочных объектов (обычно через общий путь), поэтому вы напрямую не решаете эту проблему. Первоначальный разработчик должен проверить эту информацию.

Answer 4

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

Добавление ссылки на DLL по полному пути будет ошибкой разработчика, равно как и добавление исходного файла по полному пути будет ошибкой.

Answer 5

Практическое правило : Если проект не является частью решения, ссылка на освобожденные dll-файлы из каталога контролируемого источника / binshare или / lib находится в дереве управления исходным кодом вашего решения. Все внешние зависимости должны иметь версионные библиотеки DLL, которые находятся в этом каталоге / binshare.

Я понимаю, что твой сотрудник делает в отношении удобства. Однако этот подход разработчика диаметрально противоположен правильному управлению конфигурацией / сборкой.

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

Answer 6

Почему бы не настроить частную ленту NuGet? Таким образом, существует только одна копия зависимости (репозиторий NuGet), и несколько проектов могут ссылаться на нее. Несколько версий зависимости могут сосуществовать, и каждый проект может ссылаться на свою версию, если это необходимо. Кроме того, TFS Build может восстанавливать пакеты во время сборки.

Настройка VS: https://www.visualstudio.com/en-us/docs/package/nuget/consume

Answer 7

Я думаю, что этот подход совершенно противоположен тому, что я бы назвал лучшей практикой. Я думаю, что было бы гораздо лучше не допускать сторонние двоичные файлы из исходного репозитория и ссылаться на них через что-то вроде репозитория Maven в процессе сборки. Помещение dll в исходный репозиторий излишне раздувает содержимое репозитория и приводит к получению проектов, занимающих значительно больше времени, чем необходимо. Это также делает независимое управление версиями сторонних двоичных файлов запутанными, поскольку они не ссылаются на версию по имени, а подразумевают ссылку на dll определенной версии, хранящейся в папке lib проектов.