Расположение сторонних DLL в контроле версий для .NET Project

Question

Что было бы идеальным местом (каталогом) для проверки в сторонних ссылочных библиотеках для проекта .NET в системе контроля версий. Обычно я видел, как большинство людей помещают их в корзину, чтобы среда выполнения могла автоматически получать эти файлы. Однако это правильный путь.

Изначально я хотел иметь отдельный каталог, параллельный bin, называемый lib, который будет содержать все сторонние библиотеки DLL, но для этого нужны изменения в файле конфигурации приложений, чтобы каталог lib выбирался во время выполнения. Моя идея заключается в том, что lib будет содержать сторонние dll, а bin будет содержать проекты Binary (может быть Dll или Exe)

Что является предпочтительным способом? Концентрация выше - это местоположение в системе контроля версий, а не только в физической файловой системе.

Answer 1

Мы используем следующую структуру каталогов (более подробная информация доступна в моем блоге ):

Solution\
  Libraries\
    third-party DLLs here
  Source\
    Project1\
    Project2\

Каждый проект ссылается (используя вкладку «Обзор» в диалоговом окне «Добавить ссылку») на сборки в папке «Библиотеки». Они автоматически копируются в папку bin каждого проекта во время компиляции. (Папка «Библиотеки», конечно, предназначена для контроля версий.)

Answer 2

Пусть отдельный каталог содержит сторонние сборки (это упростит управление в системе контроля версий), а затем создайте ссылки в вашем проекте на эти сборки. Затем при сборке ваши сторонние сборки будут скопированы в ваш \bin, и вам не придется вносить какие-либо изменения в конфигурацию.

Answer 3

Я полагаю, что сторонние библиотеки DLL будут использоваться в более чем одном вашем проекте. Следовательно, размещение DLL непосредственно в bin каждого проекта означает, что в итоге вы получите столько же копий DLL (в VCS), сколько есть проектов, что не изящно. Как отметил Эндрю Х., если библиотеки DLL действительно распространены, их следует поместить в общий каталог, к которому будут обращаться все другие проекты, которым это необходимо. Единственный улов здесь - возможность различать разные версии одной и той же DLL: со временем вы можете получить что-то вроде:

/common/ThirdPartyLibrary.dll  (version 1.2)    
/common/ThirdPartyLibrary.dll  (version 1.3)

Лучший из известных мне пока способов переименования сторонней библиотеки DLL с явным номером версии и обращения к этому новому имени в вашем проекте, так что ваш проект всегда будет обязательно ссылаться на правильную версию. , Как:

/common/ThirdPartyLibrary_v1.2.dll    
/common/ThirdPartyLibrary_v1.3.dll