Управление ссылками в системе контроля версий с помощью Visual Studio

Question

У меня проблемы с управлением ссылками .dll в проектах в Visual Studio.Все зарегистрированные ссылки .NET и COM работают нормально, но когда дело доходит до файлов .dll на диске, если я ссылаюсь на свои файлы на диске, мои коллеги будут пропускать ссылки, потому что они могут иметь его в другом месте на диске и т.д.В Visual Studio есть переменная окружения, такая как $ PATH или что-то вроде этого, чтобы на каждом компьютере были пути, по которым он сначала будет искать, прежде чем сказать, что не может найти ссылку?Или лучше сохранить ссылки на .dll в системе контроля версий?

Хорошо, все работало отлично.В VS я просто добавил папку к решению, добавил dll в папку и добавил все в систему контроля версий.Я ссылался на эти библиотеки в отдельных проектах, и когда я получал последнюю версию с других компьютеров, она правильно связывалась.Спасибо, ребята

Answer 1

Это работает для меня, как в Subversion, так и в VSS.

\root
    \trunk
       foobar.sln (solution file goes here)
        \References
            foo.dll (3rd party, ie. you don't compile this)
            bar.dll
            (Don't put dll's for Project 1 here, Visual Studio will take care of it)
        \Project1
           .proj file goes here
              \bin  (don't put dll's here!)
        \Project2  (This might reference Project1

Не помещайте dll в \ bin, потому что такие репозитории, как VSS, делают их доступными только для чтения, что прерывает очистку и повторную сборку.

Visual Studio не понимает зависимости выше уровня решения, поэтому, если у вас есть решения, зависящие от решений, вам придется показать это на своем сервере сборок / сборке.

Answer 2

Мне нравится добавлять папку решения в решение, в которое я затем помещаю все свои внешние DLL. Оттуда я ссылаюсь на это, а не на конкретную папку на ПК.

Так что да, они в источнике, но почему бы и нет.Особенно при управлении обновлениями.

Прекрасно работает для меня.

Answer 3

Создайте папку «ссылки» в системе управления версиями, которая содержит все необходимые ссылки сборок.Если для этих сборок доступен источник, сохраните его.

Я думаю, что хорошей практикой является включение всех сборок, которые не являются частью платформы ОС или .NET.Например, вам не нужно устанавливать Enterprise Library или какие-либо другие сборки при начале работы с новой установкой разработчика (на новом компьютере или переустановкой ОС).

Answer 4

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

• 3rdParty - ссылка svn: externals на любые сторонние dll, необходимые из общего набора.
• Ссылки - svn:внешняя ссылка на папку «Сборки» любых собственных проектов.
• Сборки - это то место, куда пойдут результаты сборки проекта.Таким образом, другие проекты, которым может понадобиться ссылаться на сборки, имеют единственное место для проекта, и использование svn: externals может контролировать, какую версию они хотят использовать.

\root
     \Common.3rdParty (common third party dlls)
     \Solution
        \Project1
           \3rdParty (svn:externals links to common third party dlls that are needed)
           \Assemblies (Project's build output)
           \References (svn:externals links to referenced project "Assemblies" folders)
           \[Project's Folders...]
        \Solution.sln

Подробнее здесь

Answer 5

Общее правило: поместите dll в систему управления версиями и по возможности добавляйте ссылки по файлам проекта, а не по dll

Answer 6

Если ваши DLL-файлы присутствуют в системе управления версиями, то все, что вам нужно сделать, - это щелкнуть правой кнопкой мыши папку «Зависимости и пакеты» в решении (которое находится в Source Control Explorer) и получить его последнюю версию.

Вы найдете файлы .dll в вашей системе.