Блог

Когда мне нужно добавить ссылку на библиотеку, мне всегда говорили использовать метод «добавить существующий проект» и ссылаться на сам проект внутри моего решения.

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

Хотя я нахожу эту систему действительно сложной (я предполагаю, что потребуется много работы, если программа, указывающая на более старую версию dll, обновлена и нуждается в некоторых изменениях в этой dll), они, похоже, находят это довольно удобным.

Каковы наилучшие методы для этого? Прямое связывание dll? Связывание проекта? И почему? Любая информация приветствуется!

Заранее спасибо!

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

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

Этот Add existing project метод полезен, когда вы хотите ссылаться library project на то, что разрабатывается параллельно, и вы хотите, чтобы test/use это types было и methods , и этот Add existing project метод () не будет использоваться для добавления ссылки pre-compiled dll на файлы ().

Прочитайте статью Project Reference (MSDN).

Вы бы включили его в проект, если хотите одновременно работать с библиотекой. И это будет происходить в основном для небольших библиотек, которые будут распространяться вместе с вашей программой (папка bin).

Когда сборка (будет) установлена в GAC и, следовательно, имеет свой собственный цикл выпуска, имеет смысл ссылаться только на двоичный файл.

Также возможны несколько комбинаций из вышеперечисленного.

Добавление скомпилированных DLL-файлов происходит в основном, когда код более или менее заблокирован (код уровня архитектуры), который вы вряд ли когда-либо меняете, например

1) уровень связи (удаленный доступ / wcf)

2) Общий уровень графического интерфейса (мастера / диалоговые окна)

3) Уровень безопасности (материал azman)

вам нужно только изменить, когда ваш продукт переходит в другое направление, скажем, он использует для использования .net remoting в качестве связи, теперь он будет использовать WCF

Использование проектов в качестве ссылки, когда вы часто меняете проекты, на которые ссылаются ссылки, также Visual Studio хорошо определяет порядок построения проектов.

Хотя подход вашей компании, вероятно, не очень распространен среди разработчиков Microsoft, он довольно успешно используется в мире Java. В долгосрочной перспективе это, вероятно, лучше контролируется, чем любая альтернатива, но без достаточного количества вспомогательных скриптов / программ (которые, например, обновляют проекты / решения автоматически, когда это необходимо), это может легко стать неуправляемым. В мире Java это напрямую поддерживается такими инструментами, как Maven.