Comments 56
Наверное, можно было бы вынести функционал в модули, а основной файл заставить подгружать новые или перегружать изменённые модули: изменения ведь обычно локальные. Перезапуск тогда не понадобится совсем.
А зачем вообще нужно обновлять клиента ?
Чтобы исправлять найденные ошибки.
Это не просто "клиент-сервер", там всё гораздо сложнее. Несколько серверов БД, плюс интеграция с смс-центром для отсылки оповещений, плюс приём USSD-запросов от инженеров, плюс ещё до хрена всего в одной куче, взаимодействующего друг с другом. В общем, под клиентом подразумевается сложный программный комплекс. Даже, в некотором роде, программно-аппаратный.
Это не просто "клиент-сервер", там всё гораздо сложнее. Несколько серверов БД, плюс интеграция с смс-центром для отсылки оповещений, плюс приём USSD-запросов от инженеров, плюс ещё до хрена всего в одной куче, взаимодействующего друг с другом. В общем, под клиентом подразумевается сложный программный комплекс. Даже, в некотором роде, программно-аппаратный.
С точки зрения безопасности довольно опасное решение, особенно если программа запускается с повышенными привилегиями.
Используемые файлы хоть и нельзя заменить, зато можно переименовать. Свою утилиту обновляю переименованием старого файла и копированием нового в тот же каталог. Старый после освобождения удаляется вручную. Программа работает в терминале, старая версия нормально работает, у вновь подключившихся запускается новая версия.
Заем вручную? Идея с переименованием самая правильная. Старые переименовывается в какой-нибдуь _tmp001.$$$ а программа при старте косить все _tmp???.$$$ которые удастся удалить. Именно так я всегда и делал. Очень красиво, просто и безопасно. Причём программа обновляла сама себя, что решало проблемму с правами - она согздавала исполняемый файл с правами равными своим. Потом переименовывала себя. Потом переименовывала новый файл. А при следующем перезапуске удаляла весь мусор.
Вы конечно извините меня, я не самизнаетекто, но это бл**ять, такую ху***йню писать в блог, да ещё и выносить на главную... бред. Гениальное решение, блин, я смеюсь. Поиск по маске...
а вот зря минусуете. я на эту совершенно пустую заметку время потратил. подумал, "о, интересно" - открыл страничку, приготовился внимательно читать, изучать, а мне тут лапшу на уши вешают.
в общем, извиняться автору не надо, уже наср... но задуматься, стоит ли писать всякую банальщину на хабр, надо. детский сад.
болеете графоманией - заводите свои блоги, как я.
в общем, извиняться автору не надо, уже наср... но задуматься, стоит ли писать всякую банальщину на хабр, надо. детский сад.
болеете графоманией - заводите свои блоги, как я.
Решение оказалось действительно простым. Настолько простым, что кажется до него может додуматься даже школьник. И ведь действительно может! А умудренный опытом программист возможно начнет возводить сложную систему там, где этого совсем не нужно.
Я понимаю ваше негодование, вы ожидали увидеть готовый рецепт, рабочий код. Но ведь так даже лучше: все обошлось без кода.
Я понимаю ваше негодование, вы ожидали увидеть готовый рецепт, рабочий код. Но ведь так даже лучше: все обошлось без кода.
а я на ваш пустой комментарий время потратил :)
я вот чево подумал, если приложению не требуется работать под оч. большими нагрузками можно было бы даже незаметно для пользователя это сделать. Т.е.:
1. Качаем новый файлег.
2. Запускаем.
3. Согласовываем действия старой и новой версии.
4. Переключаеми ввод/вывод на новую версию.
5. Закрываем старую программу.
6. Прописываем в скрипт запуска путь к новой версии
Вот как то так ...
1. Качаем новый файлег.
2. Запускаем.
3. Согласовываем действия старой и новой версии.
4. Переключаеми ввод/вывод на новую версию.
5. Закрываем старую программу.
6. Прописываем в скрипт запуска путь к новой версии
Вот как то так ...
поставьте на файловый сервер *nix +samba там можно удалять и заменять открытый файл, виндовс программисты умудряются найти проблему на пустом месте :)
> Неплановый запуск программы – вещь очень нежелательная. Перезапуск занимает пару минут, но за это время может проскочить важное событие, которое не будет отслежено.
1) а чем он отличается от планового? почему за время планового перезапуска важное событие не может быть пропущено?
2) это значит что, любой segfault или unhandled exception = потенциально потерянные важные события/данные? не страшно программировать в такой среде? :) а BSoD? а отказы оборудования? сколько "важных событий" вы уже пропустили и просто об этом не знаете?
по-моему вы просто решали не ту проблему. ну и, как уже было сказано, файлы можно просто переименовывать.
1) а чем он отличается от планового? почему за время планового перезапуска важное событие не может быть пропущено?
2) это значит что, любой segfault или unhandled exception = потенциально потерянные важные события/данные? не страшно программировать в такой среде? :) а BSoD? а отказы оборудования? сколько "важных событий" вы уже пропустили и просто об этом не знаете?
по-моему вы просто решали не ту проблему. ну и, как уже было сказано, файлы можно просто переименовывать.
>а чем он отличается от планового? почему за время планового перезапуска важное событие не может быть пропущено?
Придётся объяснять специфику.
Программа обеспечивает мониторинг состояния базовых станций (это, естественно, дублируемый мониторинг) и автоматизацию регистраций проникновений на них. На каждом отдельном рабочем месте, грубо говоря, мониторится свой регион+свой радиокоммандер. От инженера, работающего на станции, в любой момент может прийти какое-то оповещение, на которое программа должна среагировать. Например, он может через USSD запросить список аварий на станции. Или, что важно, может сам послать сообщение о каком-то событии.
Если своевременной реакции не будет - инженер будет звонить оператору, это потерянное время и для него, и для оператора.
Плановый перезапуск совершается тогда, когда инженеров на базовых станций региона нет. Обычно это раннее утро.
>это значит что, любой segfault или unhandled exception = потенциально потерянные важные события/данные? не страшно программировать в такой среде? :) а BSoD? а отказы оборудования? сколько "важных событий" вы уже пропустили и просто об этом не знаете?
Нет, как видите, не значит. Во-первых, как уже сказано, мониторинг дублируется. Во-вторых, потеря информации невозможна - возможно только увеличение времени реакции на них.
Новые версии мониторинга обкатываются очень серьёзно. В бетах, конечно, ошибки допускались, но с проверенными версиями за два года проблем не было абсолютно никаких (тьху-тьху).
А СЭСов я не видел уже лет пять. Тем более - на работе. Даже если что-то и случится - это нештатная ситуация, которую техподдержка исправляет очень быстро в любое время суток.
Придётся объяснять специфику.
Программа обеспечивает мониторинг состояния базовых станций (это, естественно, дублируемый мониторинг) и автоматизацию регистраций проникновений на них. На каждом отдельном рабочем месте, грубо говоря, мониторится свой регион+свой радиокоммандер. От инженера, работающего на станции, в любой момент может прийти какое-то оповещение, на которое программа должна среагировать. Например, он может через USSD запросить список аварий на станции. Или, что важно, может сам послать сообщение о каком-то событии.
Если своевременной реакции не будет - инженер будет звонить оператору, это потерянное время и для него, и для оператора.
Плановый перезапуск совершается тогда, когда инженеров на базовых станций региона нет. Обычно это раннее утро.
>это значит что, любой segfault или unhandled exception = потенциально потерянные важные события/данные? не страшно программировать в такой среде? :) а BSoD? а отказы оборудования? сколько "важных событий" вы уже пропустили и просто об этом не знаете?
Нет, как видите, не значит. Во-первых, как уже сказано, мониторинг дублируется. Во-вторых, потеря информации невозможна - возможно только увеличение времени реакции на них.
Новые версии мониторинга обкатываются очень серьёзно. В бетах, конечно, ошибки допускались, но с проверенными версиями за два года проблем не было абсолютно никаких (тьху-тьху).
А СЭСов я не видел уже лет пять. Тем более - на работе. Даже если что-то и случится - это нештатная ситуация, которую техподдержка исправляет очень быстро в любое время суток.
а зачем вы придираетесь? почему вас волнуют чужие страхи?
может быть, у вас проблемы в семье? не в порядке здоровье? затянувшаяся депрессия и вы вымещаете её на других?
вы хотите поговорить об этом?
:)
шутка.
не стоит из мухи раздувать слона. небольшую локальную проблему чаще всего проще решить так же локально, чем пересматривать весь проект целиком и менять всё глобально :)
может быть, у вас проблемы в семье? не в порядке здоровье? затянувшаяся депрессия и вы вымещаете её на других?
вы хотите поговорить об этом?
:)
шутка.
не стоит из мухи раздувать слона. небольшую локальную проблему чаще всего проще решить так же локально, чем пересматривать весь проект целиком и менять всё глобально :)
Используем Click Once в составе Visual Studio 2005. Предлагает обновиться при запуске программы (постоянно работающие программы обычно запускаются при загрузке системы), пользователю только надо нажать Ok. В принципе быстро и эффективно, для тех, кто пишет на VS.
Минусы:
-пользователю все таки надо что-то нажимать, елси доступна новая версия.
-бывают глюки после крупных апгрейдов, программа не стартует (лечится полной переустановкой)
-какая-то муть с сертификатами (по умолчанию создается на год, как сделать больше пока не ясно) но я не копался толком)
-без перезапуска программы не обновиться (если программа работает в круглосуточном режиме)
-только для win
Плюсы:
-установка с веба (правда только с ie+NET 2.0).
-все версии сборок хранятся на сервере.
-при отсутствии доступа к серверу запускается последняя рабочая версия.
-ну и все плюсы администрирования в связи с автоматическим обновлением.
Минусы:
-пользователю все таки надо что-то нажимать, елси доступна новая версия.
-бывают глюки после крупных апгрейдов, программа не стартует (лечится полной переустановкой)
-какая-то муть с сертификатами (по умолчанию создается на год, как сделать больше пока не ясно) но я не копался толком)
-без перезапуска программы не обновиться (если программа работает в круглосуточном режиме)
-только для win
Плюсы:
-установка с веба (правда только с ie+NET 2.0).
-все версии сборок хранятся на сервере.
-при отсутствии доступа к серверу запускается последняя рабочая версия.
-ну и все плюсы администрирования в связи с автоматическим обновлением.
Да, click once хорош, однако когда необходимо обновлять системную утилиту этот вариант не подходит.
Мне приходилось разрабатывать net-службу мониторинга изменений конфигурации спец-программы. Я решил вопрос созданием сервиса на сервере обновлений (HTTP) который выдавал последнюю версию и ссылку на нее. После скачивания версии (msi файл) происходила деинсталляция установленной версии, а затем инсталляция новой. Перезапуск был нежелателен, но на другой велосипед времени не было.
Мне приходилось разрабатывать net-службу мониторинга изменений конфигурации спец-программы. Я решил вопрос созданием сервиса на сервере обновлений (HTTP) который выдавал последнюю версию и ссылку на нее. После скачивания версии (msi файл) происходила деинсталляция установленной версии, а затем инсталляция новой. Перезапуск был нежелателен, но на другой велосипед времени не было.
click once - это копия java web start? ;)
Не разумней ли подобные системы проектировать под вебинтерфейс?
скорее всего речь идет о каком-то специфическом софте, которым никто не доволен, включая начальтсво, но поскольку все более-менее работает, а данег жалко, его продолжают использовать и мучаться.
Ситуация прямо противоположная. То, что вы описали, было раньше. Новая система написана с учётом всей специфики, работает как часы, и нравится абсолютно всем. Для веб можно было бы спроектировать только интерфейсную часть мониторинга, которая, по сути, никому не нужна, а для автоматизации всё равно пришлось бы сочинять какие-то нативные решения.
А почему нельзя было разместить для всех ярлык (.lnk) и при выходе новой версии программы изменять его?
Ярлыки на каждом рабочем месте (~10) менять геморно, даже если автоматизировать этот процесс. Хотя, как вариант, можно было вместо обновлялки сделать ещё один ярлык, который и править вручную =). Вот вам и ещё более простое решение =)
столько проблем изза изначально неправильно спроектированной системы
прога клиента не должна слушать сообщения, она их должна запрашивать у надежного хранилища и помечать обработанные оператором
и тогда не возникнет проблем с обновлением клиента
прога клиента не должна слушать сообщения, она их должна запрашивать у надежного хранилища и помечать обработанные оператором
и тогда не возникнет проблем с обновлением клиента
на примере СПС КонсультантПлюс: один .exe и обновляемые *.res файлы, при запуске *.exe и обнаружении нового *.res автоматически используется он, а не устаревший
Знакомая ситуация, раньше писал для бухгалтерии ПО. И когда приходилось обновлять появлялись те же трудности, что и у автора. Я пошел немного другим путем. Все машины были настроены на один ярлык на сервере. Когда я выкладывал обновление, то менял путь в свойствах ярлыка. И все кто запускали программу, запускали уже новую версию. Но автор пошел дальше, он автоматизировал процесс.
Замечу, что когда обновления были связаны с изменением структуры базы, то все равно приходиться делать по старинке.
Замечу, что когда обновления были связаны с изменением структуры базы, то все равно приходиться делать по старинке.
Шо за кустарщина? :)
Мой компьютер > Управление > Общие папки > Открытые файлы > Правой кнопкой на файле, "Отключить"
Или в командной строке:
net file
И потом:
net file /close
И никаких программ-загрузчиков :)
В случае, если программа запускается локально, а не с сетевой шары, тоже есть замечательнейший способ подмены файлов без программ-загрузчиков. Файл кладется рядом со случайным именем, пусть "tmp_12345.exe", рядом создается файл tmp_12345.bat и запускается. Содержимое (за синтаксис ВАТ-файлов не ручаюсь):
---- begin tmp_12345.bat ----
:copy
copy tmp_12345.exe MyLockedFile.exe /Y
if errorlevel goto :copy
del tmp_12345.exe
del tmp_12345.bat
---- end tmp_12345.bat ----
Мой компьютер > Управление > Общие папки > Открытые файлы > Правой кнопкой на файле, "Отключить"
Или в командной строке:
net file
И потом:
net file /close
И никаких программ-загрузчиков :)
В случае, если программа запускается локально, а не с сетевой шары, тоже есть замечательнейший способ подмены файлов без программ-загрузчиков. Файл кладется рядом со случайным именем, пусть "tmp_12345.exe", рядом создается файл tmp_12345.bat и запускается. Содержимое (за синтаксис ВАТ-файлов не ручаюсь):
---- begin tmp_12345.bat ----
:copy
copy tmp_12345.exe MyLockedFile.exe /Y
if errorlevel goto :copy
del tmp_12345.exe
del tmp_12345.bat
---- end tmp_12345.bat ----
а что произойдёт, если запущенная программа обратится к своим ресурсам в удалённом файле?
Это по поводу 1-го варианта? Пользовались таким долго, и никаких проблем никогда не возникало.
Наверное, все-таки исполняемый файл с сетевого ресурса грузится в память целиком. Можно поставить эксперимент, собственно :)
Наверное, все-таки исполняемый файл с сетевого ресурса грузится в память целиком. Можно поставить эксперимент, собственно :)
Думаю, что зависит от программы и, может быть, системного окружения (памяти стало не хватать и ресурсы были выгружены).
Когда я ещё программировал под Windows, я иногда вручную загружал ресурсы (например, графику или звук) может быть, это как раз тот случай?
Точно не знаю, как реагирует запущенная из сети программа на удаление своего выполняемого файла, но много раз видел, как запущенная с компактдиска программа рушилась при попытке закрыть её, если диска не было в дисководе
Когда я ещё программировал под Windows, я иногда вручную загружал ресурсы (например, графику или звук) может быть, это как раз тот случай?
Точно не знаю, как реагирует запущенная из сети программа на удаление своего выполняемого файла, но много раз видел, как запущенная с компактдиска программа рушилась при попытке закрыть её, если диска не было в дисководе
А куда у Вас ведет work dir приложения? Ведь в случае запуска с сети он ведет на сеть же? И разделяется сразу несколькими пользователями, что не есть хорошо, если туда что-то писать (какие-нибудь логи и т.п.) или хранить настройки в файлах. Можно, конечно, temp dir пользоваться, который у каждого пользователя будет локальным, но это тоже не очень удачное решение.
Может уже было, но читать комменты неохота…
Как не упустить «важное событие»:
Разделить программу на две части: одна только логгит события (обновляется редко), другая их просматривает и делает всё остальное (обновляется чаще). После перезапуска вторая прога нагоняет события из упущенного прошлого.
Не всегда конечно сработает, но… Есть ещё языки с динамической подгрузкой кода. В дотнете развита концепция версий одного и того же «модуля» — кажется их даже можно подменять на лету (в некоторых языках точно можно).
Как не упустить «важное событие»:
Разделить программу на две части: одна только логгит события (обновляется редко), другая их просматривает и делает всё остальное (обновляется чаще). После перезапуска вторая прога нагоняет события из упущенного прошлого.
Не всегда конечно сработает, но… Есть ещё языки с динамической подгрузкой кода. В дотнете развита концепция версий одного и того же «модуля» — кажется их даже можно подменять на лету (в некоторых языках точно можно).
В случае появления нового билда, хорошо бы уведомить тех кто держит запущенными старые версии..
Автор безусловно молодец.
Единственное что могу по-рекомендовать - иногда поглядывать за действиями ненавистной всеми мегакорпорацией Майкрософт. Они эту задачу уже давно решили через ClickOnce. Разумеется не дословно, но общий подход такой.
Единственное что могу по-рекомендовать - иногда поглядывать за действиями ненавистной всеми мегакорпорацией Майкрософт. Они эту задачу уже давно решили через ClickOnce. Разумеется не дословно, но общий подход такой.
Я не понял, в чем именно проблема. Если ты разработчик программы, то тебя никто не ограничивает в средствах реализации:
1. Веб-интерфейс. Здесь все понятно? Нет залоченного файла, хотя эта проблема решается достаточно легко сторонними программами.
2. Разнесение запускаемого интерфейса и функциональных, подгружаемых в процессе работы модулей.
3. А вообще непонятно решение собрать в одну кучу пользовательский интерфейс и систему снятия статистики. Держи 2 сервера, на которых в качестве сервиса крутится программа для сбора. В случае остановки сервиса для обновления на главном сервере, второй сервис следит за пополнением БД. Тогда обновление серверной и клиентской части происходят раздельно и абсолютно безболезненно. А если клиентская часть будет реализована через веб-интерфейс или терминальные решения, то система будет более гибкой и масштабируемой.
Возникнут вопросы по реализации - милости прошу в личку.
1. Веб-интерфейс. Здесь все понятно? Нет залоченного файла, хотя эта проблема решается достаточно легко сторонними программами.
2. Разнесение запускаемого интерфейса и функциональных, подгружаемых в процессе работы модулей.
3. А вообще непонятно решение собрать в одну кучу пользовательский интерфейс и систему снятия статистики. Держи 2 сервера, на которых в качестве сервиса крутится программа для сбора. В случае остановки сервиса для обновления на главном сервере, второй сервис следит за пополнением БД. Тогда обновление серверной и клиентской части происходят раздельно и абсолютно безболезненно. А если клиентская часть будет реализована через веб-интерфейс или терминальные решения, то система будет более гибкой и масштабируемой.
Возникнут вопросы по реализации - милости прошу в личку.
Sign up to leave a comment.
Тихое обновление без отрыва от работы