В Windows, по крайней мере, запущенное приложение блокирует свой собственный файл .exe и все статически связанные файлы .dll. Это не позволяет приложению обновлять себя напрямую, по проводам, если оно хочет предотвратить перезагрузку (если перезагрузка в порядке, приложение может передать флаг MOVEFILE_DELAY_UNTIL_REBOOT
в MoveFileEx и может свободно «перезаписывать» свой собственный .exe). , так или иначе задерживается). Вот почему обычно приложения не проверяют наличие обновлений на собственном .exe, но запускают шим, который проверяет наличие обновлений, а затем запускает «настоящее» приложение. Фактически, "shim" может быть даже сделан самой ОС, благодаря правильно настроенному файлу манифеста. Приложение, созданное в Visual Studio, получает его как готовый инструмент, см. Развертывание ClickOnce для приложений Visual C ++ .
Типичное приложение Linux не обновляется само по себе из-за множества вариантов ОС. Большинство приложений распространяются как исходные, запускаются через какую-то версию auto-hell для самостоятельной настройки и сборки, а затем устанавливаются через make install
(все это можно автоматизировать за пакетом). Даже приложения, которые распространяются в виде двоичных файлов для конкретной разновидности Linux, не копируют себя, а вместо этого устанавливают новую версию бок о бок, а затем обновляют symbolic link
, чтобы «активировать» новая версия (опять же, программное обеспечение для управления пакетами может скрыть это).
Приложения OS X либо попадают в корзину Linux, если они имеют вкус Posix, либо в настоящее время попадают в корзину приложений Mac AppStore, которая обрабатывает обновления для вас.
Я бы сказал, что когда вы сами обновляете себя, вы никогда не достигнете изощренности любой из этих технологий (ClickOnce, RPM, AppStore) и предложите пользователю ожидаемое поведение в отношении обнаружения, обновления и удаления. Я бы пошел по течению и использовал эти технологии на соответствующих платформах.