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