Как лучше всего хранить библиотеки DLL и ссылаться на них?
Часто разработчик из моей команды создает новый проект Visual Studio и ссылается на DLL где-нибудь на своем локальном компьютере (например, C: \ mydlls \ homersimpson \ test.dll). Затем, когда я получаю проект из репозитория системы управления версиями, я не могу создать проект, потому что у меня нет указанной DLL в том же месте на моем компьютере.
Как лучше всего хранить разделяемые библиотеки и ссылаться на них?
Ответы 7
Лучшая практика, которую я ожидал бы, если бы ваш репозиторий SC включал и обеспечивал соблюдение относительного расположения ссылочных объектов для вас (обычно через общий путь), поэтому вы не имеете дело с этой проблемой напрямую. Первоначальный разработчик должен проверить эту информацию.
Правильно - «Перейти прямо в dll-hell. Не пройти Go, ...»
Если сборки нет в GAC, создайте каталог с именем dependencies и добавьте туда все сборки. Папка и сборки добавляются в систему управления версиями. Правило состоит в том, что для любого проекта в системе управления версиями все, что требуется для сборки, - это выполнить проверку и построить проект (или запустить какой-либо инструмент, который также зарегистрирован в проекте).
Если вы добавляете папку в решение и добавляете сборки в папку решения, это также дает разработчикам визуальную подсказку, которая указывает, какие внешние зависимости присутствуют ... все зависимости находятся в этом каталоге. Относительные пути гарантируют, что Visual Studio сможет без проблем найти ссылки.
Для больших решений с более чем 20 проектами это значительно упрощает жизнь!
Обычно я создаю папку lib в своем проекте, куда помещаю dll, на которые есть ссылка. Затем указываю ссылку на dll в папке lib. Таким образом, каждый разработчик может построить проект после получения из системы управления версиями.
Если это проект, который был построен на дому, вы также можете добавить этот проект в свое решение.
Это тоже была моя первая мысль. Единственный недостаток, который я вижу, заключается в том, что если у вас есть обычно используемая DLL, она будет в системе управления версиями в нескольких местах для каждого проекта, который на нее ссылается.
@ vg1890: несколько копий DLL могут быть преимуществом, это позволит каждому проекту потенциально использовать другую версию DLL.
Я рекомендую GAC наряду с управлением версиями. Таким образом, используя предварительно созданное событие, вы можете установить эту DLL из общего репозитория в свой GAC.
Я думаю, что сейчас предпочтительнее хранить артефакты извне и включать их во время компиляции, используя что-то вроде Artifactory, NuGet, Maven и так далее.
Если вы вернете фактические библиотеки DLL в систему управления версиями, вы сможете ссылаться на них по относительному пути, и все разработчики автоматически получат любые зависимости при следующем обновлении проекта.
Добавление ссылки на DLL по полному пути будет ошибкой разработчика, так же как добавление исходного файла по полному пути будет ошибкой.
Вы возвращаете свои двоичные файлы в систему контроля версий исходного кода?
Нет, не мои собственные двоичные файлы. Я предположил, что исходный вопрос касается какой-то сторонней DLL, которая не была построена вместе с проектом.
Хорошо, это имеет больше смысла. То же самое мы делаем со сторонними библиотеками.
Практическое правило: если проект не является частью решения, ссылайтесь на выпущенные библиотеки DLL из каталога / binshare или / lib, контролируемого исходным кодом, который находится в дереве управления исходным кодом вашего решения. Все внешние зависимости должны иметь версионные библиотеки DLL, которые находятся в этом каталоге / binshare.
Я понимаю, что ваш коллега делает с точки зрения удобства. Однако подход этого разработчика диаметрально противоположен правильному управлению конфигурацией / сборкой.
Пример: если вы используете блок приложения MS Data в качестве зависимости в своем приложении, вы должны ссылаться на правильно выпущенный двоичный файл, вместо того, чтобы получать последнюю версию из исходной магистрали разработчика MS.
Ваше первое предложение написано на английском? :) Может быть, какие-нибудь запятые или союзы помогут мне это понять?
Я думаю, что этот подход прямо противоположен тому, что я считаю лучшей практикой. Я думаю, что было бы намного лучше, если бы сторонние двоичные файлы не попадали в исходный репозиторий и ссылались на них через что-то вроде репозитория Maven в процессе сборки. Помещение dll в исходный репозиторий излишне раздувает содержимое репозитория и приводит к тому, что получение проектов занимает значительно больше времени, чем необходимо. Это также делает независимое управление версиями сторонних двоичных файлов запутанным, поскольку не ссылается на версию по имени, а скорее подразумевает ссылку на dll конкретной версии, хранящейся в папке lib проектов.
Почему бы не создать частный NuGet-канал? Таким образом, существует только одна копия зависимости (репозиторий NuGet), и несколько проектов могут ссылаться на нее. Могут сосуществовать несколько версий зависимости, и при необходимости каждый проект может ссылаться на другую версию. Кроме того, TFS Build может восстанавливать пакеты во время сборки.
Настройка VS: https://www.visualstudio.com/en-us/docs/package/nuget/consume
Как не? Вы не включаете все связываемые модули в SCC?