Результаты поиска
Решение deployment, CM, InstallShield
Люди,
У нас есть 4 или 5 утилит, которые работают в сочетании с нашим приложением. Эти утилиты представляют собой либо .bat файлов, либо VB приложения, PowerBuilder и т. д. Я пытаюсь управлять этими utils в системе управления версиями и пытаюсь найти лучший способ назначить им версии. Прямо сейчас разработчики используют метаданные системы управления версиями-в частности, метку-для хранения номера версии инструмента.
Моя цель состоит в том, чтобы иметь индивидуальные пакеты InstallShield для каждой утилиты, а также простые средства для управления и назначения номеров версий этим пакетам.
Вы бы рекомендовали отдельный файл .ini с информацией, или хранить информацию в самом файле InstallShield .ism, или просто использовать информацию о метаданных из средства управления версиями?
UPDATE :
Мне нравится эта идея, Орион. Но у меня есть одна забота. Скрипт, увеличивающий номер версии... он не может быть достаточно умен, чтобы увеличить основное число и т. д. право. напр. если один из utils имеет версию 1.2.3, и мы находимся в точке, где новая версия является 2.0.0. Сценарий может быть не в состоянии справиться с этим.
Я думаю, что это во многом связано с нашими методами ветвления-у нас их нет. Люди думали, что раз уж утили такие маленькие, то источник может и не нуждаться в ответвлениях.
413   3   22:42, 20th August, 2020
Решение deployment, CM, InstallShield
Люди,
У нас есть 4 или 5 утилит, которые работают в сочетании с нашим приложением. Эти утилиты представляют собой либо .bat файлов, либо VB приложения, PowerBuilder и т. д. Я пытаюсь управлять этими utils в системе управления версиями и пытаюсь найти лучший способ назначить им версии. Прямо сейчас разработчики используют метаданные системы управления версиями-в частности, метку-для хранения номера версии инструмента.
Моя цель состоит в том, чтобы иметь индивидуальные пакеты InstallShield для каждой утилиты, а также простые средства для управления и назначения номеров версий этим пакетам.
Вы бы рекомендовали отдельный файл .ini с информацией, или хранить информацию в самом файле InstallShield .ism, или просто использовать информацию о метаданных из средства управления версиями?
UPDATE :
Мне нравится эта идея, Орион. Но у меня есть одна забота. Скрипт, увеличивающий номер версии... он не может быть достаточно умен, чтобы увеличить основное число и т. д. право. напр. если один из utils имеет версию 1.2.3, и мы находимся в точке, где новая версия является 2.0.0. Сценарий может быть не в состоянии справиться с этим.
Я думаю, что это во многом связано с нашими методами ветвления-у нас их нет. Люди думали, что раз уж утили такие маленькие, то источник может и не нуждаться в ответвлениях.
511   3   20:27, 4th August, 2020
Остановка MSI от запуска EXE в контексте SYSTEM
У меня здесь проблема с MSI deployment, над которой я работаю (используя InstallShield ). У нас есть программа, работающая в фоновом режиме, которая должна выполняться для каждого пользователя, и она должна запускаться автоматически без вмешательства пользователя.
Проблема заключается в том, что объект групповой политики / Active Directory (GPO/AD) deployment приложение запускается в контексте SYSTEM до входа в систему, а не как пользователь, который собирается войти в систему. Приложение может выполняться только один раз на пользователя, и кажется, что процесс SYSTEM предотвращает запуск процесса USER. Это означает, что PCs необходимо перезагрузить дважды, прежде чем программное обеспечение может быть развернуто для пользователей. Как нам остановить это?
В основном текущий рабочий процесс является:
- Установки/обновления... убить фоновое приложение
- Установка новых файлов
- Запуск фонового приложения
Это работает для опубликованных приложений и интерактивных установок MSI - это только 'assigned' приложений, которые, кажется, имеют проблему. Как Шаг 3 происходит в контексте SYSTEM, а не в контексте пользователя :(
В идеале, я бы попросил команду разработчиков исправить файл EXE, чтобы предотвратить запуск в контексте SYSTEM, но это цикл выпуска, и я ищу решение на основе установщика для промежуточного периода.
(Я не знаю Installscript... Поэтому я предполагаю, что VBScript -это, вероятно, путь, если нет родного материала InstallShield, который я могу использовать.)