Pull to refresh

Comments 26

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

Тот подход работал порадовал надежностью.
Этот готовый компонент совсем не торт.
Чтобы использовать его надо запускать не само приложение, а Appstart.exe, которое должно висеть в памяти, да и юзер может завершить процесс.
На сервере должен быть включен HTTP-DAV и корректно обрабатываться метод PROPFIND.
Обновление на сервере должно быть выложено не в архиве, а просто папкой.
Если вы захотите добавить возможность работы zip архивами, то надо будет практически полностью переделать этот компонент. А на писан он не очень изящно и присутствует много лишних телодвижений.

Никому не рекомендую использовать этот компонент.
Если вам нужно обновлять только одно своё приложение — используйте архитектуру, которую описал kent44, или описанную в этой статье.
вопрос автору: если виндовый сервис стучится в сеть, продуман ли вариант борьбы со злоумышленниками? Ну подменили в hosts ip-адрес веб-сервиса и всё, нам скачалось что попало, какой-нибудь зловредный код
Лично у меня никакие механизмы защиты не реализованы.
Вопрос безопасности тут выльется в еще одну статью, а то и в серию.
ну почему же, можно было бы пару «бла-бла защита» сказать :)
Мне вот не очень нравится держать в системе лишние сервисы. Я бы убрал отсюда промежуточное звено «Служба» и просто запрашивал бы у пользователя права на установку как это делает другой софт.
Это не единственная задача сервиса.
И что вы имеете в виду под «другой софт»?
Приведите примеры, пожалуйста.
Если вы откроете службы Windows, то скорее всего обнаружите там два сервиса:
Google Update Service (gupdate)
Google Update Service (gupdatem)
Второй судя по всему Manual.
Google не входит в ваш «другой софт»?
А еще я могу обнаружить там апдейтеры Java и Apple.
Жалко, что не каждая программа вешает для своего обновления службу. Ведь их так мало запущено.
Для вас это может быть и не очевидно, но суть реализации и заключается в том, чтобы уменьшить количество процессов и служб, которые занимаются обновлением.
Если у вас несколько приложений, то все они смогут «получать» обновления от одного единственного Windows-сервиса.
Не надо будет для каждого приложения запускать лаунчер, держать соединение с сервером обновлений.
Теоретически в системе всеми обновлениями может заниматься один процесс, и возможно этим процессом скоро станет ClickOnce, если разработчики перестанут делать свои «велосипеды».
А разработчики перестанут делать свои велосипеды тогда, когда им будет достаточно функционала ClickOnce. Сейчас, к сожалению, это не всегда так.
Сейчас я еще раз перечитал что там «дано» и чуть больше понял идею. Если софта действительно очень много, то может это и имеет смысл. Но тогда это лучше было вынести если не в топик, то хотя бы в текст до ката.
У меня нету таких служб. И не надо устраивать мусорку.

Пусть пользователь запускает лаунчер, который произведёт обновление, а потом запустит саму программу. Или сразу запустит, а в фоне скачает обновления и обновит при следующем запуске.

В качестве примера — посмотрите Оперу.
Невозможно читать код от «Source Code Highlighter». Зачем он делает эти ненужные пустые строки?
Мне тоже не нравиться, но ничего лучше не нашел. Вы чем пользуетесь?
Что за ерунда, переделал все через s-c.me/, опять эти пустые строка вылезли…
Source Code Highlighter не вставляет пустые строки. проблема в самом парсере.
Не раскрыта тема политики формирования обновлений, т е не скачивать каждый раз полный апдейт, а хранить несколько видов апдейтов:

— Полное;
— В рамках мажорной версии;
— От предпоследней версии к последней.

Это эффективно когда пользователей много, дистрибутивов различных версий доступно для установки так же много и трафик минимизируется.
Как-то подумали-подумали, и решили новое приложение на Silverlight делать, проблема с обновлениями отпала сама собой.
UFO just landed and posted this here
Тоже была задача справляться с обновлениями. Сразу оговорюсь, что это подходит для приложений которые доступны только для внутреннего пользования внутри корпоративной сети.

Для этих целей отлично подошёл самописный консольный launcher который лего конфигурировался при помощи задания пару строк в App.config:
— директория установки приложения (destination_dir);
— директория для проверки обновлений (update_dir обычно серверная то есть куда вы публикуете новую версию приложения);
— имя исполняемого файла приложения;

Суть в том, что пользователь всегда запускает приложение при помощи этого launcher, который сам сраванивает update vs destination директории, обновляет destination файлы если в update есть новые версии. Версии для удобства публикуются каждая в новой директории по маске наподобие 20111102.0048 (дата и время)

Решение очень удобно и хорошо зарекоммендовало себя на PROD-е.
Главное преимущество этого подхода — нет необходимости изменять приложение чтобы оно поддерживало обновления
минус — работает для относительно простого деплоймента внутри локальной сети (при желании на самом деле можно расширить как-нибудь)
В одном из проектов начинал реализовывать примерно такой же подход, потом надо было что-то добавить, потом требования ещё слегка изменились. В общем, через несколько итераций плюнул и связался с ClickOnce, о чём ни разу не пожалел. Теперь все небольшие личные проекты, в которых планируется хоть какое-то развитие, сразу разворачиваю через ClickOnce.
UFO just landed and posted this here
Пару раз упомянули про несовершенство ClickOnce, а в чём оно? Вкратце можете сообщить?
Sign up to leave a comment.

Articles