Где хранить внешние файлы DLL? - PullRequest
51 голосов
/ 25 ноября 2010

В моем проекте я использую сторонние библиотеки. Я включаю их, используя папку ссылок в Visual Studio.

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

Ответы [ 8 ]

64 голосов
/ 25 ноября 2010

Вот что я делаю:

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

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


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

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

  1. Сделайте то же самое для простых зависимостей DLL-файлов (где у них нет NuGet pkg)
  2. Включите «Восстановление пакета» длярешение
  3. Измените файл packages.config, если необходимо, чтобы заблокировать версию для определенного пакета
  4. Не храните пакет сами в системе управления версиями (установите игнорировать для Git , Mercurial и т. Д.)

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

9 голосов
/ 25 ноября 2010

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

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

Папка trunk содержит копию источника, над которым я сейчас работаю.Кроме того, есть каталог 'lib', который содержит все сторонние сборки, на которые ссылается мой проект.
(я ссылаюсь на сборки в этой позиции).

Папка "Releases" содержит ветвиствола.Например, когда выпущен v1, из ствола берется ветвь, так что у меня есть копия исходного кода и всех его зависимостей, необходимых для сборки версии 1 приложения.(Это удобно для исправления ошибок. Исправьте ошибку в этой ветке, объедините исправление со стволом, перестройте эту ветку, и у вас будет фиксированная версия v1 вашего приложения.)(Да, также ссылки на сборки).Таким образом, очень легко, если другой коллега также должен работать над проектом.Он просто получает последнюю версию из системы управления исходным кодом, и у него (или у нее) есть все для компиляции и сборки).

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

4 голосов
/ 08 февраля 2012

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

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

Затем прочтите этот документ NuGet, чтобы получить крем-де-ла-крем :

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

4 голосов
/ 25 ноября 2010

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

4 голосов
/ 25 ноября 2010

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

2 голосов
/ 25 ноября 2010

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

1 голос
/ 25 ноября 2010

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

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

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

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

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

Вы должны решить, к какой категории относится ваш компонент.

1 голос
/ 25 ноября 2010

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...