Russian Qt Forum

Всем доброго здравия!

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

Теперь к сути:

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

Как я это вижу:

  1. На сервере имеется xml-файлик/запись в БД, где содержится номер актуальной версии ПО.

  2. Клиент после авторизации на сервере, запрашивает актуальную версию.

  3. В зависимости от разницы версий, будут скачены те или иные файлы.
  *Для каждой версии в БД будут храниться свои файлы.

  4. После того, как все необходимые файлы загружены, ПО предлагает перезапустить себя.

  5. При завершении ПО, запускается Updater, проверяющий наличие файлов обновлений (возможно читающий xml c инструкциями)

  6. Updater при завершении запускает наше ПО. Задача выполнена.

Сам код меня честно говоря не интересует.
Нужно представление о "правильности" подхода.

С удовольствием прочитаю Ваше мнение по моему вопросу.

вроде здраво все. Так и делается

Здраво то оно здраво, у меня этот механизм реализован. Однако, апдейтер у меня тоже на Qt и он требует тот же QtCore библиотеку для работы. А если мне надо обновить библиотеки? Решил что для винды напишу апдейтер на WinAPI, но потом подумал, а нафига? Если можно просто скачивать запакованый к примеру в 7zip пакет самораспаковывающийся и запускать его. Опять же придется качать больше чем требуется. Про линукс я молчу, там либы в другом месте сидят, а тот же 7zip пакет уже не распакуется, надо чтото типа deb и rpm собирать.
Присоединяюсь к автору и тоже хотел бы узнать как сие правильно реализовать.

Помоему всё прозрачно.

Любой самораспаковывающийся архив для обновления апдейтера.
Под виндой - тупо использовать сервер сценариев и/или батник для последующего запуска апдейтера.

Есть конечно и более долгий вариант, который использует % 80 онлайн игр - апдейтер для апдейтера :D
Точнее апдейтер разделён на 2 самодостаточные программы. Одна обновляет программу, вторая обновляет апдейтер. Ну и исходя из этого, последовательное их обновление не составляет труда.

PS скачивать больше, чем требуется Оо.

Это как?

В любом случае архив с обновлениями самораспаковывающийся будет весить меньше, чем архив + QtCore.dll.

1 - Требуется обновить только бинарник
2 - Требуется Обновить бинарник и добавить новую библиотеку
3 - Требуется сменить все библиотеки на актуальные + бинарник

Так вот в самораспаковывающийся архив в первых 2 вариантах ложить только нужные файлы? Или весь софт целиком? Никто не гарантирует что юзер не удалит предыдущую версию :) В таком случае он получит ничего не получит при распаковке)

Если обновлять через батник, то появляется тупое черное окно, так же как и обычное Win32 приложение. Конечно его можно будет запустить через CreateProcess с нужным флагом и окно не покажется, но это гемор. Мне кажется нужно чтото типа как у FileZilla скачивание инсталятора. В моей софтине инсталятора нет, поэтому и подумал что удобней будет самораспаковывающийся архив.

Вы хотите сказать, что не в состоянии запустить архиватор с параметрами? Оо

Апдейтер получает список файлов и их хеш. Сверяет файлы с хешем. Формирует список не совпадающих. Передаёт список на сервер. На сервере формируется архив с необходимыми файлами. Пересылка архива и его автоматическая распаковка.

Где вы нашли эти 3 пункта???
Где вы нашли в этих 3 пунктах проблему???
Где вы нашли проблему несуществующих файлов (их нет и хеша тоже нет, не так ли? :) )?

А батник можно и завизуализировать и сайлентом запустить, и вообще - можно сценарием сделать.

PS а если юзер в момент загрузки отвёрткой остановит диски винчестера и написает на пилот с UPS'сом? Какие файлы будут нужны заикающемуся, со вздыбленными волосами и текущей слюной, овощу? :)

Архиватор то причем? Кашу нагородили. А если нет архиватора? И зачем эти примудрости с хешем если изначально известен билд программы и на сервере хранится список тех что нужно заменить допустим?

Как нетрудно догадаться эти 3 пункта случайный набор потребностей при обновлении, не знаю на что вы с агрились.

Разберём по деталям.
1) я не агрюсь, а спрашиваю :)

2) Архиватор нужен для загонки необходимых файлов в самораспаковывающийся архив.

3) Премудрости с хешем необходимы, ибо файлы твоей программы могут отсутствовать/быть повреждёнными/быть взломанными/быть другими(пользователь решил к примеру переименовать :D)/и ещё куча вещей, в том числе и блокировка файлов.

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

PS поверь, 30% обычных пользователей удалят пару файлов твоей программы, 40% прервут загрузку/установщик/распаковку архива, а 20% с весёлым гигиканьем словят вирус, который твои ini файлы, допустим, превратит в словарь матного языка. 9% на форс мажорные обстоятельства (полетел сектор на винте и файл что? Увы, недоступен) и 1% на волю господина рандома.

PPS самораспаковывающийся архив распаковывается ВНЕ ЗАВИСИМОСТИ от наличия на компе архиваторов. А на сервере он будет, если вы его туда поставите.

Честно говоря вариант с "апдейтером для апдейтера" мне нравится больше.

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

Проверка существующих файлов и их контрольных сумм тоже хорошая идея спасибо, как то не подумал об этом.


Вернемся к абстракции...

Я вот все больше склоняюсь к хранению всех файлов в БД в чем то типа BLOB.

Таким образом будет 3 таблички - версии(id, version) + файлы(id,name,dirTo,dataBLOB) + смежная(version_id, file_id) или как там правильно не помню если честно...
 
Формирование списка файлов для загрузки получится намного проще, не придется обращаться к файловой системе а можно будет все брать прямо из БД.

Можешь хранить в веб директории и использовать для загрузки QNetworkAccessManager и QNetworkReply. Ну или по старинке по сокету.

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

sidsukama -мы рассматриваем все варианты. Обобщённый апдейтер так сказать.

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

Если залить статичные архивы, то вы будете каждый раз посылать N мегабайт клиенту. А ему нужен будет допустим 1 файл в 200 кб :)

У апдейтеров (нормальных) есть 3 варианта действий:

1. Обычное обновление (запрашивает обновление/устанавливает/пишет что готово или версия последняя).
2. Восстановление. Оно обычно идёт каждый раз при обновлении. Как раз проверка наличия файлов. Соответствие их хеша, закачка и восстановления структуры согласно вашему билду.
3. полное обновление - как раз качается статичный полный образ программы согласно билда.

PS а динамическое формирование архива - вещь простая как 2 пальца, и снимает сотни проблем.

А почему бы не написать апдейтер на boost? И слинковать статически. Тогда и с либами для апдейтера париться не придётся.

Реклатс - по секрету скажу: и на Qt можно скомпилить статически )  И на С++ и на С :D Даж на С#.

Скажу и вам по секрету, что тут свои подводные камни:
1) Лицензирование
2) Размер файла. Мне всё же кажется, что у boost будет меньше результирующий файл.


Вы тут чуть чуть не правы. Вы ставите либу наравне с языками программирования.

boost - это C++. Qt это С++. Найдёте разницу? :D
Статика вообще не нужна, если так посмотреть.

Размер тут не обсуждается. И нигде не обсуждается :D 2 мб или 3 мб с нашими сетями - ноу проблем.

PS если вы сторонник: "сбережём каждый бит, усечём всё что можно, запакуем чем угодно, но будет у нас вместо 3 мб - 2,99мб", то winApi. получится что-то вроде 100-200 кб.

Boost, Qt - это библиотеки. Части целого. Это как рассказывать о вашей пятке как об отдельной личности.

А если по теме, то можно обойтись хранением обычных статичных образов. Во избежание всяких проблем с версиями, реестром и т.д.
Просто скачивать файл с версией (тут можно даже не xml а просто plain text), сравнивать и выкачать.

И не придумывать всяких Франкенштейнов  ;D

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

Мой франкенштейн будет быстрее ваших образов % на 150.

Плюс у программы будет автоматическая проверка целостности при каждом запуске. Плюс размеры закачиваемых файлов.

Сравните что лучше:

                    Верес'штейн                                                                                                                        Reklats'штейн
Размер закачки варьируется при необходимости                                                            Размер закачки стабилен и равен установщику программы
Как вывод - можно восстановить любой файл за максимально короткое время                  Как вывод - чтобы восстановить 1 файл, нужно качать полный образ
Проверка целостности файлов программы(сравнение хеша файлов)                                 Отсутствует
Автовосстановление программы/исправление испорченных файлов                                  Отсутствует
Замена 1 файла в билде = заливка 1 файла на сервер                                                    Замена 1 файла в билде = заливка полного образа программы на сервер
Возможность полного восстановления программы(скачивание установщика)                     Имеется, происходит каждый раз при обновлении
Гибкость в настройке/смене файлов/возможности сборки                                               Отсутствует, имеется только замена образов
Автоопределение билда программы!!!                                                                            Отсутствует. Порча информации о билде = фейл

Вроде основные отличия я привёл. Выбирайте сами.

Мои выводы до понедельника:

  1. БД - содержит информацию об актуальной версии ПО.
  *версии(id, version, current) + файлы(id,name,dirTo,dataBLOB, md5) + смежная(version_id, file_id)
    Где
     current - флаг на текущую версию, для удобства отката, достаточно переместить флаг на предыдущую версию как все откатится.
     dirTo - путь в директорию из местоположения апдейтера.
     dataBLOB(varbinary) - содержание самого файла.
     md5 - для проверки файлов.

  2. Клиент после авторизации на сервере, запрашивает актуальную версию.

  3. Проводим сравнение файлов по md5, обновляем всех отличающихся.

  4. После того, как все необходимые файлы загружены, ПО предлагает перезапустить себя.

  5. При завершении ПО, запускается Updater, проверяющий наличие файлов обновлений (возможно читающий xml c инструкциями)

  6. Updater при завершении запускает наше ПО.

*аплодисменты* Успехов в начинании.

Итак.

Что мешает зашить в инсталер проверку целостности? Попробуйте поставить Qt инсталером - он стначала проверяет целостность, msi архив тоже проверяет целостность. Тем более система скидывает установочники себе за пазуху, так что потом есть возможность спокойно восстановить программу и не надо заново качать файло.

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

C++ (Qt)
#define version "1.2.3.4"

+ считать значения из реестра. Если что не так - восстановиться.

Гибкость в настройке/смене файлов/возможности сборки - если вам нужен конструктор, сходите на рынок и купите. Программа скомпилена с либой версии 1, а вы предлагаете просто заменить её на версию 1.1? Позвольте, а файл с хешами вы тоже будете хранить рядом с бинарником? Или может в реестре ;D
Зачем заменять 1 файл? Если постаралось вирьё, то лучше будет заново запустить инсталер и восстановиться.

При этом не надо будет иметь базу с файлами. Публичная папка или фтп - оттуда и скачивается вся программа.

Я проверку целостности имею в виду целостность уже установленной программы.

У тебя одна маленькая ошибочка. Ты всё зашивать пытаешься в один файл :)
Ещё и кеши туда зашить, да ещё и систему проверки. Да и автоопределение туда же. (НЕ МАТЕРИСЬ блин на форуме!)

Апдейтер же должен быть маленьким, скачивающимся быстро и иметь функцию докачки.

При всех твоих манипуляциях у тебя везде вылезает ммм... излишество? Хранить версию билда в реестре + установщик хранить "за пазухой" + всё таскать каждый билд/изменение.

Если постаралось вирьё, шанс что пострадал твой ИНСТАЛЛЕР довольно велики :) И качать его заного с полным билдом в прицепе ты будешь довольно долго :D

База с файлами - необходимость для апдейтера.(нормального такого)

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

У тебя ставка на простоту и надежду на "вирус попортит всё, а установщик раз и не тронет" и "пользователь не будет потрошить реестр". (Пользователь программу установит и она твой реестр схавает :D )
У меня ставка на живучесть и мобильность и простоту.

PS  2 разных подхода, но мой имеет преимущество. Хотя бы потому, что он содран с уже отлизанных, оптимизированных и максимально живучих систем.

Хорошо, если запаковывать нужное на сервере, то будет тупо архив скачиваться? Т.е либо мы запускаем потом архиватор с параметрами, либо юзер вручную должен будет распаковать. Так? Так вот а если нет архиватора (нонсенс но бывает)? А если и есть то какой запускать? Лучше уж тогда оставить на ручную распаковку. А если самораспаковывающийся собирать, SFX так он только под винду и только под виндой наверное и соберется. У меня на серве линь. Да и в конце концов сами говорите что скорости такие что размер не важен, моя программа в SFX с либами и прочей ерундой будет метров 10 весить. Мне кажется проще готовый пакет отдавать и запускать его.

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

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

Читайте тему. А не тупо пишите посты :)

Под линь и винду спокойно разделяется как тип, так и установщики. На то и база данных :)

И повторюсь -

всё же инсталлер мне кажется лучше всего. Он может и ключи в реестр писать, и за целостностью следит. Проблем гораздо меньше, и реализовать это проще. Программа проверяет обновления, скачивает новую версию, и сигнализирует пользователю, что есть обновления. Пользователь перезапускает программу, и скрипт сперва её обновляет, и потом запускает. Если произошла ошибка, то пользователь сам её решит, почистит место и т.д. Иначе это всё надо будет делать вам вручную. Оно надо?

Алекс - я тебе по секрету скажу - апдейтер должен быть минимален, автономен(не зависеть от реестра) и быть способным восстановить программу.

А то, что ты сейчас сказал - дело 5 минут и 3 классов. И то, я ещё с перестраховкой рассчитываю :D

И да - пользователь не должен "перезапускать программу". Это должно быть полностью автономным.

PS да, надо :) по крайней мере я бы так и сделал. Ибо Опыт, ибо Безопасность(ты сам знаешь что делает каждая часть твоего апдейтера), ибо Независимость(исходя из этого же, см. предыдущие скобки).

PPS Вот случай на этой неделе. Инсталлер инно сетап, собранный в сибири где-то, отказался запускаться на Windows 7 x64. Тупо ничего не говорит, не пишет, лог не ведёт, даже не инициализируется(тупо файл не запускается). И никто, в том числе и его добрый сборщик, незнает почему. увы. Ценой страшных усилий удалось выцепить исходный установочный файл из сибири же :) А так я буду уверен за каждый байтик своей программулины.

PPPS То что я предлагаю лишь совет, не указание. Это моё мнение и пока что преимуществ "простоинсталлера" не вижу :D

От реестра может зависеть основная программа. Кто будет писать или удалять ключи? Обычно это делает инсталлер.


Ему это и не нужно, а желательно. Инсталлер ещё ничего не установил, он просто лежит на диске и ждёт своего часа.


Если ты ГАРАНТИРУЕШЬ, что твой апдейтер не запорет в один момент программу, то я согласен. Мой опыт говорит о том, что ты такого не можешь гарантировать. Однажды он удалит и не восстановит какую-нибудь библиотеку, а ты хлопнешь себя по лбу со словами "блин, а об этом я и не подумал".


NIH синдром


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


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

Верес, меньше пафоса пожалуйста. И за мат извиняюсь.

На разработку и тестирование вашего многофункционального апдейтера будет потрачена уйма человекочасов. Вы пытаетесь построить мост посреди шоссе.
А если у человека нет инета и прога загнулась? Всякое бывает.

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

Кстати, где гарантия, что вирьё не похерит ваш апдейтер?) И да, если прога не работает - юзер идёт в установку\удаление и восстанавливает прогу. Пихать в готовую прогу ещё и функции диагностики установки - глупо.

Ну делайте как хотите :)
Алекс - у меня лежит сейчас вот на диске 2 заготовки - класс для общения клиент-сервер и класс общего назначения (ну куча всяких простых функций в нём)

Потрачу я примерно 5 минут своего времени  на создание. Примерно ещё час я сам (лично, по собственному желанию) потрачу на отладку и тестирование :) И останется собрать под разные платформы + запуск на виртуалах.

В принципе апдейтер будет готов. Но это МОЙ путь (пафос пафос нагнетаем :D) ибо я довольно много участвовал в создании подобных тем.(рабочих тем в смысле :D )

Я вам предлагаю апдейтер для любой программы. Абсолютно. Достаточно будет лишь завести записи в базе и залить файлы.

Но опять таки - решайте сами :D

PS по секрету скажу - я сторонник программ аля " запустилось, сказало - чувак ты у меня в мозге счас темечко вырезал и восстановилась для работы" :D Написание такой программы - это задачка та ещё. А пофайловый апдейтер используется в 70% онлайн проектов где-то. Ибо это надёжнее :D

PPS Хватит спорить! Вы правы и я прав :D Давайте уже отдыхать - пятница всё же :D

Ты так и не ответил ни на один вопрос. Как редактировать реестр во время установки, например создать новые ассоциации с расширениями? Как удалить такую программу, вычистив тот же реестр и roaming data?

Можно кстати посмотреть на эти классы ради интереса.

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

Апдейтер работает на двух платформах (Win, Mac). Для каждой написан с использованием родных средств создания GUI, а общая часть на ANSI C.
Сам апдейтер реализован как интерпретатор скриптов, скрипты содержатся в пакете обновления в бинарном виде (байткод). Там же содержатся и необходимые данные. Таким образом можно формировать различные сценарии обновления.

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

За год ни одной проблемы связанной с апдейтером не было =)

Alex Custov погуглите "Сервер сценариев windows".

Скрипты, которые позволяют делать с системой всё что угодно. Аналоги вроде имеются и в unix подобных системах, но в той области у меня маловато опыта.

И да, при должном желании, ручками можно прописать всё. Абсолютно. И спросить и записать и снять бд всего содержимого на диске и отправить этот списочек мне в БД :)

PS Как ты думаешь установщики пишут в реестр? :D так же и в апдейтере можно прописать. Только в апдейтере будет всё нужное и не будет наносного :D

Я про это и говорю - ты фактически напишешь свой инсталятор, второй INNO Setup, зачем на это тратить время я не понимаю. NIH синдром - одна из самых дебильных вещей в IT.


Можно, можно и свою Qt написать для этих целей, и даже (чего мелочиться) ОС, в которой не будет ничего лишнего.

Что-то никто тут о "Windows Defender", firewall, антивирусах, и прочих приблудах, запрещающих запись в папку типа C:\Program Files не вспоминает. Что же будет с замечательным маленьким апдейтером, когда при запуске под пользовательским аккаунтом ему Windows тупо не даст изменить содержимое каталога программы? Будете писать собственную службу, которая апдейтами заниматься будет? А кто тогда эту службу будет инициализировать? Будете всё же инсталлятор для приложения писать?
В Windows существует служба Windows Installer, с помощью которой по мнению Microsoft все эти задачи и должны решаться. И даже специальные средства разработки для неё имеются, умеющие в том числе атомарные бинарные апдейты делать. Правда тараканов там своих хватает. Так что дерзайте: каждый настоящий программист всё же должен хоть раз в жизни собственноручно написать файловый менеджер и автоматический обновлятель.

Хокс - я тебе по секрету скажу. Даже запись/удаление с помощью МСИ в програм файлс без полномочий НЕВОЗМОЖЕН :D

Не для того ограничения ставят, чтобы их вот так служба обходила.

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

Автоматического обновлятора нету пока вроде в общем доступе. Точнее каждый из них заточен на свою программу и "О, неожиданно" не занимаются рукоблудством, описанным в вашем случае(установка без привилегий).

PS только что поставил огранку себе на гостя. Запустил инсталлер виндосовского медиа плейера. Получил отказ об установке в данную папку :D

Рассуждение об абстрактном коне в сферическом ваакуме, если честно :) Из разряда "программисты о дизайне".

Важно представлять ЗАЧЕМ нужен инсталлятор/апдейтер и как это для юзера. От этого уже решать что как храниться и т.п.

Нормальные игрушки онлайн используют свои инсталляторы/лончеры/апдейтеры. Причем здесь как бы основные моменты:
 - сам лончер - статически собран. обновлять себя умеет (шанс порушить процесс минимален)
 - обязательная проверка по хешу и по названиям файлов. чтобы знать чего не хватает вдруг или что удалить.
 - докачка апдейтов

Все это на Qt делается безпроблемно. Я уж не говорю о том, что для "крупных" программ как игр еще и торрент в это дело встроен.

Важно также понимать:
 - сколько у программы будет юзеров
 - как часто будут апдейты
 - нужна ли "история апдейтов"

К примеру, если у вас вдруг 100500 пользьвателей с частыми апдейтами - то еще и содержать сервера придется под это дело + поле для оптимизации траффика и т.п. там неплохое.

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

Всем спасибо, очень интересный диспут.

Вижу что придется объяснить почему мне нужен сферический конь в вакууме.

Мы продаем достаточно дорогостоящее оборудование по всей РФ, на котором из софта есть только ОС, фаервол, наше ПО.

Задача состоит в том, чтобы это все чудо обновлялось САМО.
Пользователь максимум должен видеть таблички "извините сейчас оборудование производит обновление", "Производится поиск обновлений", "Проверка текущего состояния".

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

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

Ага. В принципе идеальный пользователеустойчивый вариант :D

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

Ну и  не ври тогда :D Ни 1 служба не обновит, если не будет запущена с админскими правами. А чтобы они были, нужны что? админские права :D
Копирование/удаление/перемещение/замена без прав НЕВОЗМОЖНА. В принципе :) (Анонимусы злостно взвоют на эту реплику, ну да фу на хакеров)
И МСИ запускается с правами пользователя :D

Windows Installer для того и выполнен в виде службы, чтобы запускаясь с системными (даже не админскими!) полномочиями иметь возможность выполнять все эти операции.
В любом случае, дискутировать в таком тоне я не собираюсь, тем более что суть темы уже собственно раскрыта.

Угум. И не стоит дискутировать :D Я ж говорю специально проверял - при запуске с пользовательскими правами, если нет доступа к program files(Запрещено администратором для этого пользователя), то MSI выдаёт ошибочку доступа :)

"чисто теоретически" - надеяться не стоит, но не суть.

если проблемы с интернетом, то апдейт ОБЯЗАН проходить так:
 1. определяем какие файлы повреждены из текущей версии, качаем их для _текущей_ версии
 2. определяем что нужно проапдейтить, качаем это в отдельную папочку, сверяя целостность. Апдейт локальной сборки реальный начинаем когда все файлы докачались.
 3. сохраняем текущую версию в бэкап, обновляем.

Это нужно для избежания проблем обрыва связи на середине апдейта.

Кстати есть готовые сторонные решения на эту тему, в т.ч. бесплатные, например, winsparkle или google omaha. Сам правда не пробовал, рекомендовать не рискну.

Готовые Сторонние Решение, о которых Никто Почему То не Пишет :D
И я ниразу их не видел, хотя активно пользуюсь апдейтерами и обновляторами.

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