VS Решение, проекты vs dlls best practice

Question

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

Еще один положительный или отрицательный результат - это то, что если эта библиотека обновляется кем-то еще в компании, и я затем создаю другое приложение, которое использует ту же самую вещь, которую они могли бы сломать. Если по какой-либо причине, которая не может быть исправлена ​​с текущим приложением, вы можете вернуться в исходный элемент управления и вернуться к более старой версии, но это слишком немного OTT.

Мне просто интересно, что думают другие люди по этому вопросу. Что вы обычно делаете, ссылаетесь на dll или добавляете проект в свое решение.

Answer 1

Мы храним наши производственные Dll в хорошо известном месте на сетевом диске, а ссылка - через UNC-путь DFS (без буквы диска). Таким образом, мы можем использовать разные версии используемой библиотеки одновременно, а обновления не прерывают код/​​принудительно перекомпилируют до тех пор, пока не будет использована более новая версия. Стандартная схема именования может быть использована для обеспечения того, что если проект всегда хочет использовать последнюю версию, он может.

Answer 2

Храните библиотеку в общей папке между проектами и просто ссылайтесь на нее. Таким образом, при его обновлении изменения будут сохраняться повсюду. Для отладки я думаю, что если вы сохраните файлы .pdb для библиотеки, то вы должны иметь возможность входить в DLL, однако, если вы хотите отлаживать библиотеку?

Answer 3

Вы также можете зарегистрировать свою DLL в GAC. GAC обрабатывает все ссылки, версии и т. Д. И является безопасным. Назначив сильный ключ, который является предварительным условием для dll, находящихся в GAC, у вас есть безопасный способ доступа к Dll и где вы используете общий сервер, это может быть неоценимым. На ваших сайтах, использующих эту DLL, есть центральный порт для сборки. GAC имеет целый ряд преимуществ с несколькими статьями на MSDN и, без сомнения, сотнями на Google, посвященных этому.