.Net Assembly / dll Совместное использование и развертывание

Question

У нас есть 3 программных продукта, которые используют одни и те же .NET библиотеки (код + устаревшие).
Все они используют общую функциональность, присутствующую в 3/4 библиотеки.

Я хотел знать, как и где развернуть эти библиотеки.
И это самый стандартный способ сделать это.

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

S2] Поместить его в общую папку с файлами?

S3] Помогает ли в этом System GAC?
(Поместите все 3 в GAC, и код является общим. Но я беспокоюсь о версии?)

Также, как создать развертываемую настройку для таких проектов:

D1] упаковать все dll в одну установку. Каждая установка имеет свою собственную копию.
но предположим, что если кто-то устанавливает программное обеспечение A, то для программного обеспечения B общие файлы уже присутствуют в системе.

D2] развернуть общие файлы в отдельной настройке и упаковать их с каждым .try, чтобы обнаружить, если файлы уже присутствуют, если да, не развертывать (это все еще не помогает настройке размера) Общая папка - это должна быть GAC или какая-то папка в системе? Включает в себя сложную настройку, так как она потребует проверки версий различных общих файлов.

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

Answer 1

S1 + D1 точно. По поводу «если есть обновления ...»: это скорее выгода, чем проблема. Если вы измените сборку, вам придется перестроить использующие проекты. Сценарий S1 позволяет выполнять этот проект за проектом, без ненужных зависимостей между ними.

Не используйте GAC для небольших библиотек, и это хлопотно.

Answer 2

Если ваши релизы хорошо спланированы, тогда размещение dll в GAC - хороший вариант. Вопреки этому факту, если вы добавляете какую-то небольшую функцию, а затем выпускаете свой продукт, то GAC совсем не масштабируется, потому что тогда вам придется делать параллельные выпуски всех ваших продуктов, что, я думаю, невозможно. Кроме того, GAC используется для хранения библиотек, имеющих общие функциональные возможности для всех продуктов, использующих эти библиотеки. Таким образом, вы должны быть уверены в функциональности, которую вы предоставляете для всех продуктов. Совсем не рекомендуется добавлять разные функции для каждого продукта и хранить библиотеки в GAC. Для этого вы должны быть очень точными в вашей системе версий и выпусках.

Answer 3

Я бы пошел "S1" + "D1" или "S1" + ClickOnce; он упрощает развертывание и управление версиями, а также совместим с развертыванием ClickOnce, развертыванием xcopy, развертыванием MSI, сетью и т. д. GAC не подходит для IMO. Повторные обновления; ну, вы захотите протестировать / выпустить их по отдельности, нет? У меня настроена каскадная сборка на моем сервере сборки, поэтому если я обновляю библиотеку dll, она накапливается и перестраивает все, что использует эту dll, и выше (прежде чем кто-либо скажет: да, он обнаруживает и устраняет циклы).

Подход "общая папка" имеет проблемы с разрешением DLL, поэтому сам по себе является настоящим PITA.

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

Answer 4

GAC - это место, где вы хотите, чтобы код гарантировал наличие только одной копии каждой версии. Не беспокойтесь о версиях с GAC, потому что он позволяет хранить несколько версий библиотек.

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

Answer 5

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