Автообновление в корпоративных средах (C #)

Question

У меня есть трехуровневое приложение, которое устанавливается в корпоративных средах. При каждом обновлении версии сервера также должны обновляться все клиенты. В настоящее время я предоставляю пакет MSI, который автоматически развертывается через Active Directory, однако мои клиенты (в основном по 20-300 пользователей каждый), похоже, ненавидят решение MSI, потому что оно

• Сложно запустить его (немного знаний Active Directory);
• Процесс обновления не может быть запущен сервером при обнаружении новой версии;
• Клиенты не могут устанавливать несколько версий клиента (например, 2.3 и 2.4) одновременно для общения с разными серверами;
• Сам процесс обновления не всегда работает должным образом (иногда очень странное поведение выздоравливает через несколько часов)

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

У меня не было бы проблем с написанием логики обновления самостоятельно, но там проблема в том, что пользователи, работающие с самообновляющимися приложениями, имеют слишком ограниченные права для выполнения обновления. Я обнаружил, что они могут писать в свой каталог Local Application Data, но я не думаю, что это будет типичное место для установки файлов приложения.

Вы знаете способ обновления, которое "просто работает"?

Answer 1

Вы можете несколько повторить то, что делает ClickOnce, просто настроить его под свои нужды.

1. Создайте легкий исполняемый файл, который проверяет наличие обновлений в сети или в Интернете.
2. Если есть обновления, он копирует их локально и заменяет «настоящие» файлы приложения.
3. Запускает «настоящее» приложение.

Местоположение файлов приложения должно определяться разрешениями и операционной системой. Если у пользователей есть разрешение на запись только в ограниченный набор папок, у вас нет выбора, кроме как использовать одну из этих папок. Другой вариант - предоставить начальный установочный пакет, который устанавливает легкий исполняемый файл и предоставляет разрешение на чтение / запись для определенной папки, такой как «C: \ Program Files \ MyApp». Такой подход обычно требует участия со стороны ИТ.

Надеюсь, это поможет.

Answer 2

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

Итак, интеграция очень проста, и библиотека делает почти все для вас, включая синхронизацию операций. Он также очень гибкий и позволяет вам определять, какие задачи выполнять и при каких условиях - вы устанавливаете правила (или используете те, которые уже есть). И, наконец, немаловажным является поддержка любого источника обновлений (веб, BitTorrent и т. Д.) И любого формата фида - все, что не реализовано, вы можете написать сами.

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

Это сводится к одной DLL, размером менее 70 КБ.

Подробнее на http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/

Код: http://github.com/synhershko/NAppUpdate (по лицензии Apache 2.0)

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

Answer 3

Очень сложно дать вам точные ответы, потому что важная информация о программе установки на стороне клиента не является явной. Вы устанавливаете файлы на стороне клиента в Program Files? Тогда вы можете столкнуться с проблемами, когда пользователи ограничены.

Вы не думаете, что Local Application Data - это папка для развертывания приложения, но Google это делает. Браузер Chrome устанавливается таким образом в Windows, а процесс автоматического обновления даже незаметен (что может звучать ужасно). Так почему бы не развернуть свое приложение в этой папке для пользователей с ограниченными правами? Вы можете найти больше информации об установщике Chrome здесь,

http://robmensching.com/blog/archive/2008/09/04/Dissecting-the-Google-Chrome-setup.aspx

Answer 4

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