Написал: Игорь Морковин
Кто делал многопользовательские сетевые приложения, тот знает как хлопотно обновлять версии такой программы на десятке-другом рабочих станций — то у юзера комп не работает, то самого юзера нет и никто пароля не знает, то у юзера срочных дел полно и т.д. и т.п. Конечно, можно было бы вывести им ярлык программы(с сервера) на рабочий стол, но при такой организации возникает масса других проблем(например, с индивидуальной настройкой и конфигурацией, длительной загрузкой больших программ…). Одним словом, программа при запуске должна сама обнаружить наличие своей обновленной версии(на сервере, ес-сно) и предложить юзеру обновиться и выполнить это обновление.
У CapeSoft есть такое решение на уровне шаблонов, доп. утилит и библиотек(AutoUpdate) в составе FileManager, но этот пакет недешево стоит(правда, там много и других полезных вещиц). Но в Clarion Magazin №9 за 2001 год есть статья Джефа Берлингофа «Self-Upgrading Applications» с исходными кодами в виде APP-шки. Суть в том, что создаются три дополнительных файла, хранящих инфу о приложениях, новых версиях и рабочих станциях. Этот процедуры я и использовал практически без изменений(русификация интерфейса не в счет). Т. е. встроил их в свой EXE-шник. А для отслеживания версий(правильнее — билдов) использую шаблон от ABCFree — MISC:Update and Display build number(Global).
Собственно обновление выполняется отдельной программой, которую можно указать индивидуально для каждого обновления. Эта прога запускается, если юзер согласился обновиться(еще бы он не согласился(!) — тогда просто головной EXE-шник закроется). Я, ес-сно, особенно не мудрил: написал простенькую программу копирования, которая берет список копируемых файлов, SourcePath и DestinationPath из своего INI-файла. После копирования юзер должен повторно запустить основную прогу.
Недостатки: так как BuildNumber остлеживается только в EXE-шнике, то после перекомпиляции любой DLL-ки надо перекомпилировать и сам EXE-шник. Но эти лишние минуты совершенно не в счет по сравнению с отвоеванными у юзеров временем и нервами.
Ответил: Николай Цигуро
> Кто делал многопользовательские сетевые приложения, тот
> знает как хлопотно обновлять версии такой программы на
> десятке-другом рабочих станций — то у юзера комп не
Никаких проблем. Еще в банке на CW20 был реализован комплекс порядка 15
приложений по типу конструктора. Все лежало на сервере. Ядро комплекса — EXE с программно конфигурируемым меню и тулбаром и DLL глобалов.
Кофигурации — в БД, весь остальной функционал — в DLL. Был пяток DLL общего назначения (загрузка-выгрузка док-тов, печать платежек, ЭЦП, …) и полтора десятка специального. Число пользователей комплекса — от полусотни. Все это чудненько работало на 486-sx и 10 Мб сетке на Новеле.
Все вызовы из фрейма делались через CALL. Почему?
Легко конфигурировать — все в текстах.
Легко обновлять — Если DLL не линкуется, а загружается по мере надобности, то система ее не захватывает (только на время загрузки) и ее можно в любой момент обновить не дергая юзера. Переоткрыв окно он автоматом подгрузит свежую версию.
Процесс загрузки становится совершенно незаметным, т.к. распределяется во времени. При запуске грузится лишь небольшой EXE-шник (только фрейм) и глобалы. Функционал грузится по мере необходимости — тоже весьма скромные объемы.
Конкретная конфигурация выбирается параметром (ini-файл задачи) при старте.
Общие ini лежат на сервере, личные — на станции. У каждой DLL-ки два своих инишника — сетевой и локальный. Это чтобы голова не болела о конфликте имен секций и переменных.
В каждой DLL специальным шаблоном генерировалась ф-ия, которая возвращала
список экспортируемых процедур еще какую-то ерунду, типа иконок для кнопок
тулбара. Использовалась она в редакторе конфигураций приложений.
Все обновления делали сисадмины запуская инсталятор. Обычно, когда вздумается. В тех случаях, когда модифицировалась БД (добавлялись новые файлы для новых задач и менялась прилинкованная DLL глобалов) — в ночную смену.
Ответил: Вячеслав Черников
> можно было бы вывести им ярлык программы(с сервера) на рабочий стол,
> но при такой организации возникает масса других проблем(например, с
> индивидуальной настройкой и конфигурацией, длительной загрузкой больших программ…).
Да вроде нет особых проблем. Для каждого пользователя создается персональный каталог на сервере, где лежат его настройки и служебные таблицы. Загрузка программы тоже не напрягает. Есть проект, в котором суммарный объем exe+dll около 15МБ, плюс стандартные клашины dll. Пользователи ни разу не жаловались, что несколько секунд загрузки им мешают.
Правда, сейчас все или переходят, или сразу ставят системы под терминал.
Слишком заметна разница в уровнях производительности и надежности.
Ответил: Андрей Мялин
Я решал такую задачу, но немного по другому, никаких встраиваемых шаблонов в
APP
есть программа UNIADMIN, с помощью которой можно редактировать MNU файлы — структуры менюшек со всем вытикающими характеристиками — как в Window форматере + немного расширив, редактировать конфигурационный файлы — CFG — в котором указываются список MNU файлов требующие загрузки под данную конфигурацию.
запускается UNIADMIN так же как будет описано ниже
есть программа UNISTARETER не требующая для своего запуска больше ничего (local сборка).
На входе два параметра либо если таковые отсуствуют берётся из INI под ногами — CFG файл и путь до глобальной папки.
UNISTARTER раскручивает CFG и его MNU — определяет на какие DLL, EXE… файлы ссылаются элементы меню в MNU файлах, производит синхронизацию локальной папки с глобальной если имеется в данный момент доступ к глобальноый папке, в случае отсуствия доступа синхронизация не производится и запускается тек локальная версия
ещё с глобальной папкой происходит синхронизация всех имеющихся там DLL и EXE файлов
синхронизация локальной и глобальной папок произвродится по простому -несоответствие даты или времени или размера файла — признак — файл требует обновления
ещё, если элемент меню в MNU файле ссылается на файл, которого нет в глобальной папке, производится поиск по PATH, находится — Ok, например, закрепили Calc.exe, зачем его копировать и держать в глобальной папке.
ещё он синхронизирует универсальный загрузчик UNILOADER
после того, как синхронизация произошла UNISTARTER запускает по RUN загручик программы UNILOADER с параметром CFG файл
который открывает фрейм, раскручивает CFG файл и строит МЕНЮ программы по инфо из MNU файлов, соответсвующие DLL ки по элементам меню подымаются не сразу, а при первом обращении с которым.
чтобы нормально обрабатывать события в Frame из своей программы, есть соответствующий INTERFACE с помощью которого можно управлять этим Frame
в результате нет никакой привязки к версии программы, признаком обновления файла является несовпадение его характеристик в глобальной и в локальной папках.
один UNISTARTER служит пускачём для нескольких разных программ.