Как включить KB2670838 в программу установки InstallShield 2013?

Я использую InstallShield 2013 для создания базового установщика MSI для приложения, для которого требуется Обновление платформы Windows KB2670838 .

Для .NET frameworks и других требований я выбираю их в InstallShield в разделе Redistributables. KB2670838 недоступен.

Если я загружу KB2670838 из Microsoft, я получу файл .msu. Можно ли это как-то включить в установщик, чтобы он автоматически устанавливался при необходимости? Если нет, есть ли способ остановить установку и сообщить пользователю, что «KB2670838 требуется, но не установлен. Получите его здесь ...»?


powershell windows-installer wmi installshield hotfix
person shoelzer    schedule 13.03.2014    source источник
comment
Shoelzer: Пожалуйста, проверьте мою рекомендацию MSI еще раз. Я бы не использовал PSInfo, а поиск файлов, чтобы обеспечить надежность вашей установки в будущем.   -  person Stein Åsmul    schedule 14.03.2014
comment
@Glytzhkof Ваши ответы полны полезной информации и определенно помогли, но не совсем ответили на вопрос, который я задавал. Предварительное условие или пакет - это то, что мне нужно было знать. Вот почему я проголосовал за ваши ответы, но принял ответ Майкла.   -  person shoelzer    schedule 15.03.2014
comment
В ПОРЯДКЕ. Я бы не стал включать исправления Windows в свой собственный пакет, поэтому я ответил так, как ответил. Это связано с вероятностью того, что исправление может быть объявлено устаревшим в какой-то момент, и что оно обычно либо установлено в целевой системе, либо явно запрещено к установке из-за корпоративной политики.   -  person Stein Åsmul    schedule 15.03.2014
comment
@Glytzhkof Хороший вопрос. Итак, как мне заставить InstallShield прервать работу и дать пользователю приятное сообщение, чтобы он знал, что делать?   -  person shoelzer    schedule 16.03.2014

Ответы (5)


arrow_upward
2
arrow_downward

@Glytzhkof Хороший вопрос. Итак, как мне заставить InstallShield прервать работу и дать пользователю приятное сообщение, чтобы он знал, что делать? – shoelzer 1 час назад

Тогда я просто добавлю новый ответ - слишком долго, чтобы писать в комментарии.

  • Найдите сведения о файле, которые необходимо отсканировать, в разделе «Дополнительная информация: информация о файле» в этой статье kdb: http://support.microsoft.com/kb/2670838/en
  • Выберите несколько файлов для сканирования и добавьте в качестве файлов для поиска в Installshield (см. снимок экрана ниже). Вы указываете свойство для каждого файла (FILE1FOUND, FILE2FOUND, FILE3FOUND и т. д.), и если поиск соответствует сведениям о файле (версия, размер, дата и т. д.), для свойства устанавливается полный путь к файлу. файл. В противном случае свойство не определено или имеет значение по умолчанию (на снимке экрана показан предопределенный поиск, а не поиск файлов, но вы поняли).
  • Наконец, вы добавляете LaunchCondition записи для каждого файла, чтобы убедиться, что все файлы, которые вы выбрали для проверки, имеют правильную или более позднюю версию. Я предполагаю, что это в Предварительных требованиях или подобном - я не могу вспомнить. Откройте скомпилированный файл MSI и убедитесь, что он выглядит как Таблица условий запуска.

Вид поиска Installshield

Для протокола: (не входит в приведенное выше предложение)

Лично я выступаю за кодирование одного сценария для такой сложной логики, чтобы гарантировать, что логика может быть проверена в целом и критически протестирована в целом вне файла MSI. Также хорошо добавлять комментарии к такому коду, чтобы объяснить, что скрипт проверяет и почему (помогает корпоративному развертыванию). Сценарий можно запустить через десятки тестов непосредственно на машине без перекомпиляции MSI. Это может сэкономить много времени, если логика сложная. Если вы пишете скомпилированную dll, вы можете отобразить окно сообщения и подключить отладчик Visual Studio к процессу msiexec.exe (клиент или сервер, в зависимости от контекста, в котором выполняется ваше пользовательское действие) и выполнить код, встроенный в MSI. , но это выходит за рамки вашего сценария. Просто хочу упомянуть об этом для других людей, которые могут прочитать это. Также посетите сайт Стефана Крюгера installsite.com для получения дополнительной информации об отладке сложной установки. нравится.

Важно отметить, что использование сценариев обычно не рекомендуется для сценариев, в которых сценарии вносят изменения в систему, если есть встроенный способ MSI для достижения того же результата. Причина этого в том, что для скрипта, который вносит изменения в машину, потребуется указать отдельную операцию отката, чтобы MSI следовал рекомендациям. Это может быть впечатляющим объемом работы и сложности, чтобы сделать все правильно. Приведенный выше скрипт будет проверять только системные условия, поэтому поддержка отката не требуется.

person Stein Åsmul    schedule 16.03.2014
comment
Спасибо, что вернулись с этим ответом. Это как раз то, что мне было нужно. - person shoelzer; 21.03.2014
comment
Нет проблем, я добавил слишком много информации с другими ответами, прежде чем ответить на то, что вы спрашивали, но будем надеяться, что остальное будет полезно для кого-то еще. - person Stein Åsmul; 21.03.2014

arrow_upward
3
arrow_downward

В InstallShield такое обновление обычно следует доставлять в качестве необходимого компонента (Инструменты > Редактор необходимых компонентов) или в виде пакета, включенного в набор (ссылка [SystemFolder]wusa.exe для установки файла .msu). В обоих случаях это позволяет логически отделить распространяемую установку от установки вашего пакета, в то же время предоставляя пользователям единый установщик.

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

person Michael Urman    schedule 14.03.2014
comment
Согласен со всем, Майкл, за исключением случаев, когда установка является исправлением безопасности Microsoft или иным образом доставляется через обновление Windows. Затем я сообщал программе установки о предварительных требованиях, прерывал установку и заставлял их обновляться через Центр обновления Windows. Причин тому много, но самая главная — корпоративная политика. Некоторые исправления не могут быть установлены в компании время от времени, чтобы избежать поломки пользовательского сетевого программного обеспечения и тому подобного. - person Stein Åsmul; 15.03.2014
comment
Другая причина заключается в том, что исправление может оказаться устаревшим в какой-то момент, и установка должна по-прежнему разрешать установку, если все обновления файлов выполнены. - person Stein Åsmul; 16.03.2014

arrow_upward
3
arrow_downward

Список программ для установки и удаления в реестре может помочь вам получить приблизительное представление о том, что установлено:

  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Удалить

Однако, похоже, это не полный список того, что установлено: /где-адрес-удалить-программы-получить-его-информацию-из-в-реестре?forum=w7itprogeneral" rel="nofollow noreferrer">http://social.technet.microsoft.com/Forums/windows/ en-US/d913471a-d7fb-448d-869b-da9025dcc943/откуда-адресные-программы-получают-свою-информацию-из-реестра?forum=w7itprogeneral

Другим способом может быть использование информации о файле из статьи базы знаний: http://support.microsoft.com/kb/2670838/en (Дополнительная информация: Информация о файле) и используйте функцию WIX/MSI AppSearch/LaunchCondition. Это должно сработать, хотя я нахожу синтаксис немного нелогичным.

Другой подход — написать пользовательское действие и объединить эти два источника (добавить/удалить запись и информацию о файле). Такое настраиваемое действие не внесет изменений в систему и, следовательно, менее проблематично, чем другие настраиваемые действия, вызывающие проблемы с откатом. Я считаю, что проще тестировать и поддерживать пользовательское действие на случай, если в какой-то момент потребуются дополнительные предварительные условия. Хотя это дело вкуса. Я просто считаю, что проще запустить предварительный сценарий для выбранных файлов, чтобы проверить, правильно ли он их идентифицирует и работает, как ожидалось, чем продолжать запускать файл MSI для каждого теста.

Вот аналогичный вопрос с некоторыми указателями от superuser.com: https://superuser.com/questions/521175/determine-if-windows-hotfix-has-been-applied

И еще ссылка на serverfault.com (сайт системного администрирования). Хороший подход с использованием PowerShell, который, безусловно, можно перенести в пользовательское действие: https://serverfault.com/questions/312778/determine-if-user-has-hotfix-981889-установлено

Еще больше материала serverfault.com, включающего update.exe, WMI и сценарий Powershell для просмотра всех установленных исправлений: https://serverfault.com/questions/263847/how-can-i-query-my-system-через-command-line-to-see-if-a-kb-patch-is-installed . Рекомендуется прочитать. Microsoft: http://technet.microsoft.com/en-us/library/hh849836.aspx

PSInfo показывает установленные исправления: http://technet.microsoft.com/en-us/sysinternals/bb897550

person Stein Åsmul    schedule 13.03.2014

arrow_upward
1
arrow_downward

Позвольте мне попробовать добавить ответ в справочном стиле, так как мой другой ответ, по меньшей мере, немного органичен на данный момент - я оставлю его, поскольку он содержит обсуждение MSI. См. рекомендацию MSI в среднем разделе ниже:

WMI:

wmic qfe where "HotfixID = 'KB973687'"

PowerShell: (просто установите исправление для полного списка)

get-hotfix | findstr "981889"

Системная информация (удалить аргументы для формата списка ):

systeminfo /fo csv

PSInfo (кажется, не все на всех машинах и может работать неправильно):

PSinfo -h

Реестр (видимо, неполный список исправлений):

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall

Для использования настраиваемого действия MSI я бы на самом деле использовал настраиваемое действие, которое проверяет версии файлов, как описано в моем другом ответе. Очень надежен и учитывает, что исправление может быть устаревшим, пока файлы все еще актуальны.

Ссылки:

person Stein Åsmul    schedule 14.03.2014

arrow_upward
0
arrow_downward

Имел ту же проблему и решил ее, добавив предварительное условие сценария PowerShell и пакетный файл для его выполнения.

Файл pre.ps1 выглядит примерно так:

function TestConnection
{
    Test-Connection -ComputerName "8.8.8.8" -Quiet
}

get-hotfix -id KB2670838
if(!$?){
    #SourceURI = "https://download.microsoft.com/download/1/4/9/14936FE9-4D16-4019-A093-5E00182609EB/Windows6.1-KB2670838-x64.msu";
    #$FileName = $SourceURI .Split('/')[-1]
    #$BinPath = Join-Path $DownloadPath -ChildPath $FileName
    Invoke-Webrequest -Uri $SourceURI -OutFile $BinPath
    #Start-Process -FilePath $BinPath -ArgumentList "/q /norestart" -Wait -NoNewWindow
}

файл pre.cmd выглядит примерно так:

@echo off
::set PS_FILE=%~dp0Prerequisite.ps1
set PS_FILE=%~dpn0.ps1
set PS_EXEC_PATH=%SystemRoot%\sysnative\WindowsPowerShell\v1.0\
set PS_EXEC_PATH=%SystemRoot%\System32\WindowsPowerShell\v1.0\
::set PS_EXEC_PATH=%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\
set PS_EXEC_PATH=
set PS_EXEC=%PS_EXEC_PATH%powershell.exe
echo %PS_EXEC%
echo %PS_FILE%

::%PS_EXEC% -file %PS_FILE% set-executionpolicy remotesigned
::%PS_EXEC% -NoProfile -ExecutionPolicy Bypass -Command "& '%PS_FILE%'"
::This is with admin rights
%PS_EXEC% -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%PS_FILE%""' -Verb RunAs}"

::pause
person Randall Flagg    schedule 19.02.2017