Приветствую всех!
Некое фоксовое приложение, собранное как exe-модуль, запускается всеми пользователями из одной сетевой директории. Но встает такая проблема - если нужно обновить модуль, приходится выгонять всех из программы (а это порядка 200 человек). Может, существует какое-то решение, или другой вариант сборки, чтобы после запуска модуля юзерами exe-файл был доступен для изменения?

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

Вопрос этот уже подымался, ответ был НИКАК.
Я решил эту проблему перенеся программу на локальные машины пользователя,
и при запуске она проверяет на наличие новых версий на сервере (AGETFILEVERSION),
И если версии не совпадают, то программа запускает с параметрами отдельную программу (например update.exe), а сама закрывается.
После обновление всех необходимых файлов на локальной машине, update.exe вновь запускает программу и пользователь продолжает работу.

Использую следующую схему:

1. Юзер запускает локльный ехе-шник.

2. EXE-шник с "сопутствующими" файлами и папаками лежит на разделяемом ресурсе.

3. В домене прописана политика на копирование "проги" на клиента при входе в домен.

4. Для "горячего" обновления exe-шника используется вызов из самой проги "обновлялки".

4.1. "Обновлялка" "гасит" все открытые экземпляры проги (если внутри них нет окрытых "не сохраненных" окон/форм )

4.2. Затем запускает копирование проги с "файлами и папаками" на клиента.

4.3. Затем запускает саму прогу (если надо), после чего "обновлялка" заканчивает работу.

Почему никак. Пусть все запускают не сам EXE, а например такой VBS:
Можно этот же VBS периодически опрашивать самой программой на предмет "не изменилась ли дата/размер/сигнатура файла VBS". Если изменилась (т.е. админ отредактировал этот файл, подменил версию EXE), то программа "самозавершает работу". Пользователи снова запускают VBS, а там уже указание на другой EXE

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

Что-то у меня так не получается.
m:\po\Zapusk.exe - запускает m:\po\Proga.exe - после этого все равно файл Proga.exe не доступен для изменений. У вас не так?

of63
Почему никак. Пусть все запускают не сам EXE, а например такой VBS:

Dim WSHShell, fso, FileDll
Set WSHShell  = WScript.CreateObject("Wscript.Shell")
Set fso       = CreateObject("Scripting.FileSystemObject")

FileDll = "dlls.vbs"  ' в этом файле можно делать "автоматическую" установку рантайма фокса, например, и другие вещи
if fso.FileExists(FileDll) Then  ' а если файла нет, то ничего страшного
   WSHShell.Run FileDll,0,true
End if
WSHShell.Run "MyFolder\myProg2.exe"  ' собственно запуск EXE, нужной версии (версии EXE лежат рядом)

Можно этот же VBS периодически опрашивать самой программой на предмет "не изменилась ли дата/размер/сигнатура файла VBS". Если изменилась (т.е. админ отредактировал этот файл, подменил версию EXE), то программа "самозавершает работу". Пользователи снова запускают VBS, а там уже указание на другой EXE

И что, после такого запуска MyFolder\myProg2.exe доступен для изменения?

lili

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

Что-то у меня так не получается.
m:\po\Zapusk.exe - запускает m:\po\Proga.exe - после этого все равно файл Proga.exe не доступен для изменений. У вас не так?

в папке лежит нескольно файлов проги с разными версиями
proga.exe
proga1.exe
proga2.exe
....

zapusk.exe ищет файл проги с максимальной версией и его запускает, все не нужные пытается удалить за не надобностью (старая версия файла)





Исправлено 1 раз(а). Последнее : Vladimir Sklyar, 25.04.17 11:13

Цитата:

в папке лежит нескольно файлов проги с разными версиями
proga.exe
proga1.exe
proga2.exe
....

zapusk.exe ищет файл проги с максимальной версией и его запускает, все не нужные пытается удалить за не надобностью (старая версия файла)

ааа, теперь поняла - названия модулей разные ))

у меня это целая прога(все в одном), а не отдельные модули

lili
Что-то у меня так не получается. m:\po\Zapusk.exe - запускает m:\po\Proga.exe - после этого все равно файл Proga.exe не доступен для изменений. У вас не так?

Конечно не так. Запускать нужно не через DO - иначе это будет тот же самый процесс. Любой другой способ запуска - хоть бы и убогий RUN /N, но я предпочитаю ShellExecute(). Вторая программа вполне может быть и батником...
Городить огород из 100500 prog1.exe, prog2.exe и т.д. в общем случае нецелесообразно. Равно как и давать возможность работать в "старой" версии.

Вообще-то все это затевается для возможности удаленной работы с приложением через терминальный доступ, то есть фактически удаленные юзеры запускают exe-файл с одного компа, из одной директории. Идея с разными названиями exe-модулей пока как-то не привлекает, это на крайний случай.
К сожалению, мне не ответил пока OF63, хотя я никогда VBS не делала, но можно попробовать, если это сработает.

lili

of63
Почему никак. Пусть все запускают не сам EXE, а например такой VBS:

Dim WSHShell, fso, FileDll
Set WSHShell  = WScript.CreateObject("Wscript.Shell")
Set fso       = CreateObject("Scripting.FileSystemObject")

FileDll = "dlls.vbs"  ' в этом файле можно делать "автоматическую" установку рантайма фокса, например, и другие вещи
if fso.FileExists(FileDll) Then  ' а если файла нет, то ничего страшного
   WSHShell.Run FileDll,0,true
End if
WSHShell.Run "MyFolder\myProg2.exe"  ' собственно запуск EXE, нужной версии (версии EXE лежат рядом)

Можно этот же VBS периодически опрашивать самой программой на предмет "не изменилась ли дата/размер/сигнатура файла VBS". Если изменилась (т.е. админ отредактировал этот файл, подменил версию EXE), то программа "самозавершает работу". Пользователи снова запускают VBS, а там уже указание на другой EXE

Нет не доступен. Но рядом можно положить новый файл myProg3.exe, и сослаться в VBS на него. Юзеры потихоньку самовыйдут из myProg2.exe, и запустив снова VBS запустят myProg3.exe ...
И что, после такого запуска MyFolder\myProg2.exe доступен для изменения?

> Идея с разными названиями exe-модулей пока как-то не привлекает, это на крайний случай.
По другому никак, запущеный юзером EXE никак не заменить. Этот файл открыт юзером.



Исправлено 1 раз(а). Последнее : of63, 25.04.17 11:35

в общем, понятно, выход все-таки в разных названиях модулей

На терминальном сервере вообще нет проблем разом выгнать всех пользователей и обновить версию ПО.
Т.к. во-первых весьма часто обновление фоксового ПО заключается не только в изменении exe, но и в изменении структуры БД с которой работает этот exe - работать в "старой версии" в этом случае либо нежелательно (т.к. будет сопровождаться ошибками), либо вообще невозможно.
во-вторых "проверка при запуске" работает... ну да, только при запуске. Если пользователь месяц не будет выходить из программы, то он будет продолжать работать со старой версией.
Впрочем, как всегда - хозяин-барин. Охота сделать плохо, зачем мешать

> во-вторых "проверка при запуске" работает... ну да, только при запуске
нет не только при запуске, а по таймеру на _SCREEN, раз в минуту, например, опрашиваем, смотрим изменение сигнатуры файла VBS. При изменении делаем CLEAR EVENTS, точнее, делаем искусственное нажатие кнопки "Выход из программы". Проблемы только с модальными окнами, но и их можно порешать таймерами на модальной форме. Конечно, нехорошо делать CLEAR EVENTS, но что-то другое можно изобрести, чтобы помаячить юзеру...

Олег, а проверка при запуске и проверка по таймеру это по твоему одно и то же
Проверка по таймеру это и есть вариант реализации "выгонять пользователя из программы". Т.к. процесс их работы прерывается, формы закрываются, несохранённые изменения теряются и т.п. Это чуть другой подход (вполне рабочий, конечно же).

Не знаю, кстати, о каких "сигнатурах" идёт речь... Обычно модуль который обновляЕТ программу (не важно на vbs он написан, или это просто команды cmd в батнике, или это полноценная программа на том же фоксе написанная) не меняется при обновлении - меняется модуль который обновляЮТ - т.е. сам exe программы. Иногда для удобства вообще отдельно делают мелкий файл-маркер (например пишут туда номер версии программы - банальным текстом), не тревожа для проверок собственно "большой" файл exe-ника.

Да... Вроде просто все. Этот файл VBS и есть:
- файл-маркер,
- он же указатель, запускатель, на свежайший экзешник,
- его же сигнатуру (дату время, размер) опрашивает экзешник на предмет "не сменилось ли что в нем с момента запуска"

Если админ слазит в него текстовым редактором, (и поменяет в нем MyFolder\myProg2.exe на MyFolder\myProg3.exe, одновременно положив в рабочий каталог этот новый экзешник myProg3.exe), то датавремя файла VBS (т.е. "сигнатура" файла VBS) поменяется, что и увидят таймеры в запущенных копиях myProg2.exe, и самозавершат работу. Далее юзеры запустят снова этот VBS, а в нем уже запускается свежая версия - myProg3.exe

Или я не о том?

Ну, поскольку я не менял (точнее не хранил) никогда ни имени, ни места размещения нового файла в программе-обновляльщике (оно либо в другом файле настроек хранится, либо параметрами из "основного exe" передаётся), то у меня программа-обновляльщик практически никогда не меняется (хотя в "основной" программе есть специальная ветка для замены программы-обновляльщика).
И да, у меня программа-обновляльщик располагается локально, рядом с exe, не на сетевой шаре. В другом варианте эта самая программа-обновляльщик вообще генерируется каждый раз из основной программы (в виде командного файла bat).

Из очевидных плюсов - система работает даже если файл-шара с "обновлениями" отвалилась - просто основной exe запускается и всё... Учитывая что программа в принципе может работать не с dbf-ами на том же файл-сервере, это хорошее решение - не зависеть от работоспособности "некритического" сервера.

А необходимость обновлять определяется либо через AGETFILEVERSION для локального файла и файла в папке обновлений (в тех программах где ещё использовался "монолитный exe" - т.е. один exe файл со включенными в него всеми формами/классами/процедурами и т.п.), либо через файл-маркер (локально тоже хранится файл "с номером версии"), либо через сравнение ВСЕХ файлов в папке обновления с одноимёнными локальными файлами (последние 2 варианта - для случая маленького exe-запускальщика, который вообще практически никогда не меняется, и огромной кучи отдельных файлов vcx/scx/fxp и т.п.). Плюсы и минусы есть у каждого из вариантов...
Да, разноимённых exe я не делал никогда - всегда у программы одно стабильное имя запускающего файла

У меня много лет работает. Вызов стоит в начале самого exe-модуля.
Нам просто надо кинуть заказчику новый Exe под именем PamakCopy.exe
Он не сразу его заменит. Но при вызове работать начинает сразу.
А мы по 10 раз в день его не меняем. Короче, это реальный работающий код
Кидаю, не глядя. Что-то он дергает из самого Pamak.exe
Дополнительно напишу




Исправлено 4 раз(а). Последнее : Ydin, 25.04.17 19:15