Как вы организуете свои внешние библиотеки в большой базе кода

Question

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

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

Я такжеНеясно, можете ли вы просто перенести другую версию DLL в папку, и решение ее подхватит, или .net заставляет вас использовать определенную версию (Примечание: нам не нужно подписывать какие-либо из наших сборок)

Answer 1

У меня есть специальная папка в нашем хранилище для сторонних библиотек и библиотек DLL, на которые могут ссылаться все проекты.

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

<LibName>/Current/<LibName>.dll
<LibName>/v1.1/<LibName>.dll
<LibName>/v1.2/<LibName>.dll

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

ПРИМЕЧАНИЕ: если проект зависит от другого проекта, вам нужно использовать одну и ту же версию между проектами, поэтому лучше постараться, чтобы все использовали самую последнюю версию, если это возможно.

Answer 2

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

В дальнейшем, однако, , рекомендуется использовать NuGet для управления вашими зависимостями от сторонних библиотек. Мы только начинаем развертывать это сейчас - уже отлично подходит для внешних библиотек, таких как Prism, но также позволяет вам создавать центральные репозитории для ваших собственных общих библиотек.