Я пытаюсь найти надежный способ объединения нескольких приложений, которые могут использовать различное программное обеспечение для установки (InstallShield, MS installer Service, Wise и т. Д.), И каким-либо образом автоматизировать их установку. Я не видел ни одного продукта, который надежно справлялся бы с этим. Вот что я бы хотел:
Установите несколько приложений, которые могут использовать разные установщики.
Устанавливайте приложения, не требуя ручного взаимодействия с каждым приложением. Я бы предпочел, чтобы опция в основном установщике имела настраиваемую опцию, в которой вы можете выбрать нужные приложения, просто нажать «Установить» и установить эти приложения (но без всплывающего окна установки для этих приложений)
Основной установщик должен отображаться только в меню «Установка и удаление программ» в Windows, чтобы при удалении этого одного приложения все установленные приложения также удалялись.
Управляйте параметрами установки для каждого связанного приложения, чтобы их можно было установить в логической связанной структуре каталогов. Например, установка всех приложений в папку Program Files \ Bundled App Set.
Из того, что я исследовал, на самом деле есть всего несколько способов сделать это:
Внешняя установка, которая просто запускает установщик для каждого приложения и требует ручного взаимодействия для каждого установщика (но это нарушает почти все вышеперечисленные цели, но по крайней мере устанавливает все приложения, выбранные после взаимодействия)
Автоматическая / тихая установка при условии, что каждый установщик поддерживает ее через файл ответов или флаги, переданные установщику.
Переупаковка устанавливает с помощью программного обеспечения, которое может отслеживать изменения в системе во время установки и записывать эти изменения, которые затем переупаковываются в новый установщик. Я читал, что это не очень надежно и часто ломается. У него могут возникнуть проблемы с обнаружением таких вещей, как службы, добавленные в Windows.
Существует также 4-й вариант с использованием модулей слияния, но он будет работать только в том случае, если каждое приложение использует одну и ту же службу установщика MS. Я не перечислил это из-за этого.
Это действительно вопрос мнения о том, как лучше всего это сделать. Некоторое программное обеспечение у меня есть, и я могу его перепаковать, а другое - нет. Я бы предпочел не использовать гибридную систему, например, используя №1 и №2, но если мне нужно, я должен.
Я полагаю, что есть какой-то способ сделать это правильно, и я открыт для любых мнений или предложений, чтобы что-то вроде этого работало - и, надеюсь, в конечном итоге не будет невероятно хрупким. Может, это невозможно? Любая помощь приветствуется. Спасибо.
Я использовал технику, подобную решению pjhayward в течение многих лет. Наша компания использует сотни различных программ, некоторые от крупных коммерческих провайдеров, а другие от частных лиц. Технические навыки этих поставщиков повсюду, особенно когда дело доходит до разработки установщиков.
Я считаю, что поставляемые поставщиками устройства MSI являются золотым стандартом (хотя есть еще много вариантов дизайна упаковки). Используя бесплатный инструмент Orca от Microsoft (я полагаю, встроенный в один или несколько SDK их платформ), довольно легко создать файлы Transform, чтобы преобразовать эти пакеты в наш типичный макет. Мы настраиваем меню «Пуск» для группировки программ по функциональным категориям, мы меняем каталог установки для группировки приложений по поставщикам внутри папки Program Files и полностью удаляем ярлыки на рабочем столе. При необходимости применяются серийные номера и адреса серверов лицензий, возможно, отключена служба автоматического обновления и т. Д.
Самым большим преимуществом использования MSI является то, что групповая политика Microsoft (которая работает через Active Directory и включена во все лицензии Windows Server) может развертывать эти пакеты вместе с их преобразованиями в определенных группах машин автоматически или по запросу пользователя. Мы используем автоматический метод, назначаем универсальные приложения всем машинам, приложения САПР тем, кто может их использовать, приложения Adobe - конкретным машинам (глупое лицензирование на рабочее место) и т. Д. Подробности того, как сделать это эффективно, будут отдельным вопросом SF , если его еще не спросили и не ответили.
Для многих, многих установщиков, которые не в формате MSI, мы проходим процесс переупаковки, аналогичный процессу pjhayward. Наиболее существенным недостатком этого является то, что переупакованная установка теряет весь интеллект, встроенный в исходный установщик. Чувствительность к различиям платформ (например, 32- или 64-разрядные системы) будет снижена, что может потребовать дополнительных переупаковок для каждой платформы. Решения об установке и / или обновлении сторонних компонентов будут приниматься на основе образца машины, независимо от различных начальных состояний целевых машин. И т.п.
Кстати о сторонних компонентах: мы прилагаем все усилия, чтобы установить каждый компонент в отдельном пакете, независимо от частого желания поставщиков объединить все вместе. Их стратегия имеет смысл для одного человека, устанавливающего несколько программных продуктов вручную на свой компьютер, но не работает в случае автоматизированных установок с множеством узлов и продуктов. Независимо от того, сколько поставщиков полагается на MSXML 6 или какой-либо малоизвестный инструмент управления лицензиями, мы устанавливаем каждый из них один раз, обычно перед установкой продуктов, с которыми они распространялись. Это также помогает нам свести к минимуму непреднамеренное понижение версии, поскольку мы можем легко определить, является ли связанная версия старой или новее, чем та, которую мы уже развертываем.
Мы используем программу WINinstall от Attachmate, которая в облегченном виде распространялась с компакт-дисками Windows Server 2003. У нас есть лицензия на полный продукт, но версии LE в сочетании с Orca и иногда встроенным дополнением vbscript было достаточно для моих нужд. Комментарии Эвана Андерсона о WINinstall верны, но мы смогли жить с его недостатками.
Список pjhayward (в настоящее время) затушевывает критический шаг: очистку захваченного установочного пакета перед его использованием для установки в другом месте. Нежелательные файлы и записи реестра часто собираются как часть процесса захвата, и важно идентифицировать и удалить их, прежде чем они нанесут ущерб при последующих установках. Ищите такие вещи, как ключи реестра с последовательным состоянием, которые могут быть совершенно неправильными для машины, которая некоторое время работала, и файлы кэша службы индексирования или Центра обновления Windows, которые создаются во время записи.
Обратите внимание, что лицензирование выходит за рамки моего ответа, но вполне актуально для этого типа сценария. Методы массового распространения должны быть сбалансированы с учетом фактических прав использования, предоставляемых лицензионными соглашениями каждого продукта.
Надеюсь, это поможет. Возможно, это больше, чем вы спрашиваете, и оно не идеально соответствует подходу к развертыванию, описанному в вашем вопросе, но это решение, которое мы нашли работоспособным уже много лет.
Когда вы имеете дело с программным обеспечением, для которого у вас нет кода для установки, на самом деле нет «правильного ответа».
У вас могут быть соображения по лицензионному соглашению, если вы делаете это со сторонним программным обеспечением. Server Fault не является поверенным, но если это касается чего-то, что вы собираетесь распространять за пределами своей организации, я бы попросил вашего адвоката проверить это.
«Переупаковка» для разных людей означает разное. На мой взгляд, это означает создание новой программы установки для чужого приложения. Обычно это пакеты MSI, но с тем же успехом это может быть и другая система установки. Это можно сделать с помощью автоматизированных инструментов, «вручную» или с помощью комбинации этих стратегий.
Переупаковка с использованием автоматизированных инструментов может создать безупречно работающие или безнадежно поврежденные установки. Использование инструмента для переупаковки вслепую без тщательного изучения создаваемого им пакета может привести к огромному беспорядку. Некоторые инструменты (Wininstall LE, я смотрю на вас) по умолчанию создают действительно ужасные файлы MSI (один файл на компонент, все - путь по клавишам).
Переупаковка «вручную» посредством реверс-инжиниринга «намерения» автора исходной программы установки может привести к более чистым переупакованным установкам, но вам нужно действительно покопаться и выяснить, имеет ли исходная программа установки поведение, которое вы не видите на ваша тестовая машина. Это заканчивается упражнением в обратной инженерии (и, возможно, разочарованием).
Если вы можете запустить автоматическую настройку необходимых приложений, я думаю, вы получите самую чистую конфигурацию. Если вас беспокоит список «Установка и удаление программ» (ARP), то я полагаю, что вы можете попросить «оболочку» вашего установщика изменить записи реестра ARP после завершения каждой сторонней установки, чтобы удалить все записи. (Лично я бы оставил записи ARP в покое ...)
Я был бы особенно осторожен, если этот продукт предназначен для использования COTS, чтобы вы обнаруживали существующие установки сторонних программ, которые вы устанавливаете, и обрабатываете их соответствующим образом. Я вспоминаю грубое старое образовательное программное обеспечение, с которым я имел дело, которое слепо отбрасывало любую установленную версию QuickTime и заменяло ее какой-нибудь уродливой версией Win16, нравится мне это или нет. Тьфу ...
Если вы распространяете это за пределами своей организации, и у других системных администраторов (например, у меня) есть потенциал, чтобы иметь дело с этим, пожалуйста, примите во внимание наши интересы. Мы хотели бы иметь возможность устанавливать ваш продукт в автоматическом режиме, и мы хотели бы иметь возможность поддерживать сторонние компоненты, которые вы устанавливаете.
Единственный действительно жизнеспособный вариант для достижения всех ваших целей - это вариант №3.
Основная причина, по которой переупаковка обычно ненадежна, заключается в том, что при первоначальной установке приложений все они устанавливаются в одной системе без предварительного удаления других приложений. Это означает, что вы в конечном итоге получаете зависимость от последовательности, чтобы убедиться, что у вас установлены все правильные общие библиотеки.
Если приложение A установило myLib.dll версии 1.0.0.1, а приложение B использует ту же версию, система обнаружения изменений вообще не распознает, что для приложения B требуется myLib.dll, если только оно не хранит копию в папке программы. Это особенно проблематично для приложений, использующих распространяемые библиотеки от Microsoft, которые могут быть, а могут и не находиться на целевой машине с самого начала. Большинство приложений, использующих пользовательские библиотеки, обычно хранят их в папке программы.
Чтобы вариант №3 работал даже удаленно, я бы сделал следующее:
Создайте виртуальную машину для установки различных приложений. Большинство программного обеспечения виртуальных машин, с которым я знаком, позволяет вам настроить виртуальные диски таким образом, чтобы вы могли решить, следует ли фиксировать изменения в образе виртуального диска. После того, как вы его настроите и запустите, включите указанную функцию.
Запустите программу обнаружения изменений.
Установите ОДНО приложение / обновление / что угодно, убедившись, что вы установили его в Program Files \ BundledAppsWhatever
Удалите запись реестра, которая помещала бы указанное приложение в панель управления добавлением / удалением.
Завершите процесс обнаружения изменений.
Перенесите переупакованное приложение на свой физический компьютер.
Сбросьте диск отмены виртуальной машины, чтобы у вас была чистая система.
При необходимости повторите шаги 2-7.
Теперь, с учетом всего сказанного, я не в курсе текущих предложений по переупаковке решений, поэтому я не знаю ни одного, что дало бы вам необходимую гибкость для добавления и удаления программ, как вы описали.
Если ваша компания достаточно велика (т. Е. Ее ИТ-бюджет «огромен»), есть несколько продуктов, которые работают в этом направлении.
Если вы ищете что-то для среды малого и среднего размера, вам нужно будет найти флаги установки, а затем как-то написать сценарий push.
может тебе стоит попробовать Npackd (http://code.google.com/p/windows-package-manager/)