2017-02-01 13 views
0

Наш установщик (установщик Windows) принимает параметр командной строки в форме PROPERTY = значение. Параметр будет помещать один из 3 файлов в зависимости от его значения (или его отсутствия). Это хорошо работает при установке с использованием ...Применение параметров командной строки MSI для административной установки

msiexec.exe /i filename.msi PROPERTY=value 

Я хотел бы выполнить административную установку и передать параметр PROPERTY = значение, так что извлеченное изображение отражает обычную установку, если используется этот параметр. Я попробовал следующее ...

msiexec.exe /a filename.msi PROPERTY=value /qn TARGETDIR=C:\MSIImagePath 

msiexec.exe /a filename.msi /qn TARGETDIR=C:\MSIImagePath PROPERTY=value 

msiexec.exe /a "filename.msi PROPERTY=value" /qn TARGETDIR=C:\MSIImagePath 

Третьей команду там утончается не работает, а первые два производит изображение, если установщик запускался без указания параметра PROPERTY = значение, других слов, как если я установил как ...

msiexec.exe /i filename.msi 

Как я могу выполнить административную установку переходящего в PROPERTY = значение параметра нашей MSI ожидает и имеют Извлеченный Mirror Image файлов, которые должны быть установлены при использовании этой комбинации свойств/значений ?

EDIT: Вот основная проблема, стоящая за вопросом.

Мы перемещаем наш процесс сборки на Azure VM и используем Bamboo для управления им. Мы используем InstallShield для создания инсталляторов. Когда мы создаем патчи, я понимаю, что InstallShield должен иметь доступ к образцу установки базовой линии, чтобы знать, как создать обновление MSP. Мне также сказали, что я могу создать образ установщика базовой линии, используя административную установку, которая, кажется, именно то, что мне нужно. Я не специалист по установке в команде, но пока все это имеет смысл для меня.

Когда мы создаем исходный MSI, мы вызываем IsCmdBld.exe дважды, каждый раз передавая другое имя выпуска с использованием параметра -r. Первый проход создает единый MSI, который распространяется среди пользователей. Второй проход создает несжатую папку, которая выглядит точно так, как вы видите при выполнении административной установки. Он содержит меньшую MSI, и все файлы в процессе установки извлекаются в папку. Именно эта папка InstallShield использует в качестве базового образа установщика, из которого создается логика патча.

Один из файлов, которые мы устанавливаем, может содержать 4 разных файла, определяемых параметром PROPERTY = value. Этот файл применяет определенные ограничения к продукту и предназначен для использования администраторами для ограничения некоторых функций для дополнительной безопасности. Чтобы выполнить это, проект InstallShield имеет 4 компонента, и каждый из них использует одинаковое имя файла для установленного файла и различные имена файлов для исходного файла. Я назову установленный файл файлом управления безопасностью и 4 исходными файлами файлы ограничений безопасности. Файлы ограничений безопасности не устанавливаются напрямую, один из них устанавливается в качестве файла управления безопасностью на основе параметра PROPERTY = value (или его отсутствия.)

Надеюсь, что все до сих пор имеет смысл. Поскольку у нас есть эта несколько нечетная настройка, в которой файл управления безопасностью является динамическим и изменяется во время установки, InstallShield должен выбрать один из 4 файлов ограничений безопасности, которые будут использоваться в качестве источника для файла управления безопасностью при создании MSI. Несжатый образ установщика, созданный при вызове IsCmdBld.exe, использует файл ограничения безопасности, который отличается от, чем тот, который выбран при выполнении административной установки. По этой причине при создании патчей я не могу точно воссоздать образ установки базовой линии, необходимый для создания патча. Это не было проблемой раньше, когда у нас была статическая машина сборки, а начальное состояние сборки было конечным состоянием предыдущей сборки. У нас всегда был исходный исходный образ установщика, который был создан IsCmdBld.exe.

Я могу обойти это просто, выполнив административную установку и скопировав необходимый файл управления безопасностью в исходное изображение или просто закрепив требуемое изображение базовой линии и используя это. Я просто надеялся, что смогу передать PROPERTY = значение административной установке, чтобы воссоздать базовую линию совершенно одним махом.

ответ

2

Я не думаю, что вы можете это сделать. Административная установка на самом деле не является установкой в ​​том же смысле, что и фактическая установка. Файлы размещаются в соответствии со статическими значениями в файле MSI. Одно из основных применений для административной установки - это исправление, в котором вы можете исправить административную установку или использовать два установочных образа для создания патча. Если расположение файлов не было таким, как определено в MSI, то генерация патча завершилась неудачно, потому что он не знал, где находятся файлы.

Возможно, было полезно, если вы объяснили проблему, которую пытаетесь решить, и почему это место должно быть, как если бы оно было фактической установкой (а это не так). Что вы делаете с изображением администратора, требующим макета?

+0

Спасибо, PhilDW. Это имеет смысл, и ваш разум №2 - это то, что мы делаем. Мы используем нашу первую установочную установку для установки в качестве базовой линии для создания патчей. Я добавил дополнительную информацию к моему вопросу о том, почему это не работает для нас. У нас есть несколько нетрадиционный файл, который отбрасывает оттуда административную установку от того, что она должна быть. –

+0

Я принял ваш ответ, PhilDW. Я думаю, вы правы в том, что это невозможно. Я немного изменил направление и просто закрепил первую несжатую установочную папку и сделал ее доступной для последующих сборок для создания патча. –

0

Если вы хотите, чтобы настройки свойств соблюдались на более поздней стадии установки (а не только во время административной установки), вам может потребоваться изменить таблицу свойств результата .msi. Или создать преобразование для установки свойства и применения, что во время установки:

msiexec.exe /i admin.msi TRANSFORMS=sets_a_property.mst /qn 

Это похоже на рекламу, где, в зависимости от предполагаемого использования имущества, вам необходимо убедиться, он применяется во время по требованию а не только рекламу. В этом случае вы бы применить преобразование во время рекламы с /t:

msiexec /j filename.msi /t sets_a_property.mst /qn 

Обратите внимание, что в исходном примере, targetdir=... сомнительна, так как имущество, скорее всего, TARGETDIR. Свойства с строчными буквами считаются закрытыми, и попытки установить их извне могут не соблюдаться.

+0

Благодарим вас за исправление targetdir, оно работает в нижнем, но я видел заметки о случайных символах, которые вы описываете в документе. –

+0

Вы говорите «а не во время административной установки ...». Установка администратора - это то место, где я хотел бы применить свойство. Кажется, я не могу использовать свойство при использовании msiexec/a. Если возможно, я хотел бы сделать это, чтобы файлы были извлечены в TARGETDIR при использовании/зеркалирования, что видно на пути установки во время обычной установки. Ни при каких обстоятельствах я не буду устанавливать это приложение из установки администратора. Я использую его для воссоздания образа базового установщика, из которого можно построить последующие патчи в нашем процессе сборки, и для этого мне нужно использовать параметр PROPERTY = value. –

+0

Ах, но администратор устанавливает, использует пути исходной папки вместо целевых путей папки. (См. DefaultDir в таблице Directory.) Я не думаю, что изменение этого будет полезным. –

 Смежные вопросы

  • Нет связанных вопросов^_^