Рекомендации по самообновлению настольного приложения в сетевой среде

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

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

Я хочу узнать о лучших практиках создания саморедактирующего настольного приложения. Мне особенно нравятся лучшие практики:

Вы принудительно обновляете, если программное обеспечение клиента устарело, но не прерывается при попытке установить связь с другой версией программного обеспечения или самой базы данных? Если да, то как вы обозначаете это нарушение?
Как часто вы должны проверять наличие обновлений? Еженедельно/ежедневно/ежечасно и точно почему?
Должно ли обновление быть видимым для пользователя или запускаться за кулисами с точки зрения пользовательского интерфейса?
Если вы даже уведомляете пользователя о наличии обновления, если оно не является основным обновлением? (например, исправление одной кнопки в удаленной части приложения, которое требуется только одному пользователю)
Если вы пытаетесь исправить приложение или повторно загрузите все приложение с нуля в стиле Macintosh?
Если вы разрешаете пользователям обновляться с центрального местоположения или разрешать обновление только через указанное приложение? (для закрытых бизнес-приложений).

Конечно, есть некоторые письменные правила/предложения по этому поводу? Одной из самых неприятных вещей во многих приложениях является обновление, так как трудно найти хороший баланс между "устаревшими" и "в глазах пользователей".

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

Ответ 1

Трудно дать общий ответ. Это зависит от контекста: критичность обновления, какое приложение это, пользовательские настройки, # пользователи, ширина сети и т.д. Вот некоторые из вариантов/компромиссов.

Вы принудительно обновляете, если программное обеспечение клиента устарело, но не прерывается при попытке связаться с другой версией программного обеспечения или самой базы данных? Если да, то как вы обозначаете это нарушение?

В качестве разработчика вы заинтересованы в том, чтобы все приложения были такими современными, насколько это возможно. Это уменьшает затраты на техническое обслуживание. Таким образом, если пользователь не против, вы должны обновить.
Как часто вы должны проверять наличие обновлений? Еженедельно/ежедневно/ежечасно и точно почему?

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

Зависит от пользовательских настроек, а также от типа обновления: исправления ошибок и изменения функциональности/пользовательского интерфейса (пользователь будет озадачен, увидев, что внешний вид изменился без предварительного предупреждения)
Если вы даже уведомляете пользователя о наличии обновления, если оно не является основным обновлением? (например, исправление одной кнопки в удаленной части приложения, которое требуется только одному пользователю)

те же аргументы, что и предыдущий вопрос
Если вы пытаетесь исправить приложение или повторно загрузите все приложение с нуля в стиле Macintosh?

Если размер приложения небольшой, загрузите его с нуля. Это предотвратит появление всяких странных ошибок для несоответствия между различными патчами ( "DLL hell" ). Однако для этого может потребоваться большое время загрузки или наложить тяжелую нагрузку на вашу сеть.
Если вы разрешаете пользователям обновляться с центрального местоположения или разрешать обновление только через указанное приложение? (для закрытых бизнес-приложений).

Я думаю, что

Ответ 2

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

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

Это не имеет смысла. Просто выполните обновление в конце.

Ответ 3

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

Проверить наличие обновлений для механизма обновления
Проверьте, есть ли обновления для реального приложения

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

Общей практикой является метод "ProtocolVersion", который указывает, что разрешена самая низкая/самая старая версия.

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

Ответ 4

Никогда не пытайтесь форсировать обновление, если этого не потребуют ваши адвокаты. Покажите пользователю уведомление об обновлении, которое она может принять или проигнорировать. Старайтесь не спамить одну и ту же версию слишком сильно, она отвергает ее. Помогите ей принять решение, включите ссылку для выпуска заметок или краткое изложение изменений.
Еженедельно будет хороший интервал проверки обновлений по умолчанию, но пусть пользователь выберет это, включая полное отключение проверки обновлений из Интернета. Не проверяйте слишком часто, потому что она может быть на дорогостоящем мобильном плане данных, или ей просто не нравится идея приложения, звонящего домой.
Часть проверки обновления должна быть полностью бесшумной. Если было обнаружено обновление, отобразите уведомление для пользователя. Во время загрузки и установки покажите индикатор выполнения.
Чтобы это было просто, уведомите пользователя о новой версии. Если вы не хотите раздражать их частыми обновлениями, в том числе несколькими незначительными исправлениями ошибок, не выпускайте каждую второстепенную версию в месте загрузки, просматриваемом средством проверки обновлений
Поддержание патчей для всех ранее выпущенных версий - это слишком много работы. Если размер загрузки становится проблемой, выясните другой способ, чем исправления, чтобы сделать его меньше (7-zip сжатый самораспаковывающийся exe, разделяющий приложение на несколько пакетов MSI, которые имеют независимые версии и т.д.),

Еще две вещи:

Не внедряйте движок обновления как процесс, который постоянно работает в фоновом режиме, даже если я не использую ваше приложение. Мой компьютер уже ~ 10 таких процессов забивает ресурсы, что очень раздражает. При обновлении самого механизма обновления, с одной стороны, вам нужно запустить движок, чтобы показать интерфейс выполнения установки, но, с другой стороны, процесс обновления должен быть закрыт, чтобы избежать перезагрузки, которая возникла бы из-за блокировки exe файла, Существует несколько вещей, таких как запуск вспомогательной программы из% TEMP%, с помощью диспетчера перезагрузки Windows Installer, переименование файла EXE-обновления перед запуском установочного пакета и т.д. Имейте это в виду при архивировании механизма обновления.

Ответ 5

Вы принудительно обновляете, если программное обеспечение клиента устарело, но не прерывается при попытке установить связь с другой версией программного обеспечения или самой базы данных? Если да, то как вы обозначаете это нарушение?

Спросите пользователя.

Как часто вы должны проверять наличие обновлений? Еженедельно/ежедневно/ежечасно и точно почему?

Спросите пользователя.

Должно ли обновление быть видимым для пользователя или запускаться за кулисами с точки зрения пользовательского интерфейса?

Спросите пользователя.

Если вы даже уведомляете пользователя о наличии обновления, если оно не является основным обновлением? (например, исправление одной кнопки в удаленной части приложения, которое требуется только одному пользователю)

Спросите пользователя (обратите внимание на тренд здесь?).

Если вы пытаетесь исправить приложение или повторно загрузите все приложение с нуля в стиле Macintosh?

Как правило, патч, если приложение имеет какой-либо значительный размер.

Что касается ответов "спросить пользователя", это не означает, что вы всегда запрашиваете их каждый раз. Вместо этого дайте им возможность установить, на что они должны быть запрошены, и что следует делать невидимо (и в первый раз, когда возникает данная вещь, спросите их, что делать в будущем, и помните об этом). Это не должно быть очень сложно, и вы получаете много доброй воли от большей части своей пользовательской базы, так как очень сложно фиксировать настройки для желаний всех, кто использует ваше приложение. Если у вас есть сомнения, больше вариантов лучше, чем меньше - особенно, когда они являются вариантом, который довольно тривиальен для кода.