Любые изменения на dll требуют запуска установки на компьютере пользователя

Question

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

Эти различные приложения могут относиться к одной и той же DLL. Любые изменения, сделанные в dll, требуют установки для всех приложений, которые используют его на всех ПК пользователя, на которых он установлен.

Есть ли способ развернуть DLL на ПК пользователя, чтобы получить последнюю версию без необходимости запуска установки на каждой машине?

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

Не уверен, что это имеет отношение к ответу, но я создаю установки с помощью InstallShield ограниченной версии

Answer 1

Может быть, ваша DLL принадлежит GAC (см What is the GAC in .NET?), где данный соответствующие файлы политики вы можете обновить его для всех приложений которые используют определенную версию (или ряд версий). Таким образом, вы даже можете оставить некоторые из приложений для использования старой версии, если вы внесли изменения, которые не поддерживают обратную совместимость.

Answer 2

Возможно, это аргументирует семантику, но для написания командного файла сценарий PowerShell или пакет обновления - это всевозможные «установочные» процессы.

Если я попал способы создания установки я бы ранжировать их:

1. Setup.exe
2. Нажмите После
3. PowerShell
4. Batch

Простое решение может развертывать приложение как клик один раз, когда пользователь должен проверять последнюю версию (и ее зависимости) каждый раз, когда она запускается. Если требуется обновление, Click Once обработает его без видимых на вид. Проблемы, связанные с Click Once в моем опыте, - это очень жесткая безопасность в некоторых доменах, а также отсутствие многопользовательской установки.

Если вы идете по маршруту сценария, я бы рекомендовал PowerShell, он более современен и обладает большей гибкостью, а также более читабельным.

Последний вариант, который я бы предложил, но я думаю, что атакует ваш основной вопрос напрямую. Вы можете избежать установки вообще embedding all of the resources directly into the assembly.

Answer 3

Вы можете создать отдельный MSI, который устанавливает только эту Dll. Он уже используется несколькими приложениями, и нет причин, по которым у вас не может быть еще одной «общей» установки, которая включает только эту Dll. Затем вы просто развертываете эту установку (и основное обновление) при каждом изменении Dll. Уловка состоит в том, что он должен находиться в одном и том же общем месте. И все настройки должны использовать один и тот же компонент guid, чтобы гарантировать правильность работы совместного доступа, и мне не ясно, что InstallShield LE предоставляет эти подсказки. Способ избежать этого состоит в том, чтобы создать модуль слияния для Dll и включить его во все настройки, включая тот, который устанавливает только Dll.

Плохая идея обновить Dll в режиме без Windows Inmstaller, если они были установлены установщиками Windows Installer. Windows знает, что такое установленные версииd, и от какой MSI они пришли и от версии. Если версия на диске не совпадает с установленной версией, вы можете получить вызванный ремонт, который будет запрашивать оригинальную MSI.Также обновления и исправления будут запрашивать исходный файл MSI. Если версия 3.0 фактически находится на диске, но исходный MSI установлен 3.2, то входящий патч или обновление не могут знать, требуется ли обновление файла на диске без предварительного ремонта.