Ответ 1

Это то, что я делаю:

• Создайте папку lib на уровне решения
• Загрузите и скопируйте все мои сторонние DLL файлы туда
• Ссылка из папки lib
• Поместите все эти DLL файлы в исходный элемент управления. Я использую Subversion, и я добавляю их вручную, но это одноразовое.

Вы также можете добавить папку решений и добавить их туда.

ОБНОВЛЕНИЕ 2012-12-19

Ответ выше был, когда NuGet находился в зачаточном состоянии. FWIW, мой подход, когда у нас есть элементы NuGet:

• Сделайте так, как описано выше, для простых DLL файлов (где у них нет пакета NuGet pkg)
• Включить "Восстановление пакета" для решения
• Измените packages.config файл, если необходимо, чтобы заблокировать версию для определенного пакета.
• Не храните сам пакет в системе управления версиями (set ignore для Git, Mercurial и т.д.)

Я действительно использую NuGet для управления даже внутренними зависимостями и имеет собственный фид.

Ответ 2

Как правило, структура моих проектов выглядит как минимум (как минимум):

projectname
   - trunk
       - src
       - lib
   - support
       - docs
   - releases

В папке trunk содержится копия источника, над которым я сейчас работаю. Кроме того, существует каталог "lib", который содержит все сторонние сборки, на которые ссылается мой проект.
(Я ссылаюсь на сборки в этом положении).

Папка 'релизы' содержит ветки сундука. Например, когда v1 освобождается, ветвь берется из соединительной линии, поэтому у меня есть копия исходного кода и всех его зависимостей, необходимых для сборки версии 1 приложения. (Это удобно для исправлений. Исправьте ошибку в этой ветке, объедините исправление в тубу, перестройте эту ветку, и у вас есть фиксированный v1 вашего приложения).

Все это переходит в исходный контроль. (Да, ссылочные сборки также). Таким образом, очень легко, если другой коллега должен также работать над проектом. Он просто получает последнюю версию от источника-контроля, и он (или она) имеет все на своем месте, чтобы иметь возможность компилировать и строить).

(Обратите внимание, что это также верно, если вы используете что-то вроде CruiseControl для непрерывная интеграция).

Ответ 3

Вы должны посмотреть NuGet. Это расширение управления пакетами для Visual Studio 2010, разработанное именно для того, что вы хотите.

Ответ 4

В окне свойств Visual Studio для ссылки на dll есть свойство "Копировать локальное" - установите для этого значение true, и они будут скопированы в локальный каталог bin проекта

Ответ 5

Посмотрите NuGet (менеджер пакетов для Visual Studio)...

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

Затем прочитайте этот документ NuGet, чтобы получить crème de la crème:

Использование NuGet без передачи пакетов в исходный код

Ответ 6

Посмотрите Tree Surgeon - создает дерево разработки для .NET-проекта, которое может быть хорошей отправной точкой, и оттуда вы можете импровизировать.

Ответ 7

Лично у меня есть папка в моем исходном элементе для сторонних DLL (с ​​папкой для каждой компании, организации) и ссылайтесь на них оттуда.

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

Ответ 8

Чтобы правильно ответить на это, вам нужно провести различие между средой и рабочим набором.

Окружающая среда:

• Это все инструменты и библиотеки, необходимые для создания вашего решения.
• Ожидается, что события в окружающей среде будут оставаться постоянными.
• Вещи в среде обычно версируются, и вы должны иметь несколько версий рядом.
• Вещи в среде обычно лицензируются.
• Среда не находится под контролем источника.
• Хорошим примером может служить Visual Studio.

Рабочий набор:

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

Вам нужно решить, в какой категории ваш компонент подходит.