Java MSI 静默安装程序 [英] Java MSI silent installer

问题描述

您好，我正在处理的这行代码出现问题，由于某种原因不再工作了，我正在尝试静默调用 MSI 安装程序并等待它完成，以便我可以执行下一行代码让它工作但现在不是，我尝试执行 start-process 并使用 -wait 参数，但它返回一条错误消息，当我调用msiexec.exe"时，它返回它没有 -wait 参数

Hello i'm having issues with this line of code I been working on, for some reason is not working anymore I'm trying to invoke the MSI installer silently and wait till it's done so I can execute next line of code I had it working but now is not, I tried executing start-process and using the -wait parameter but it's returning with an error message, and when I call "msiexec.exe" it doesn't have a -wait parameter

msiexec.exe /i "C:\MagtekCC\Files\Java\jre1.8.0_144.msi" /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log"
Write-Host -NoNewLine "Done.`n" -ForegroundColor Cyan
Start-Sleep -s 2



  start-process msiexec.exe  "/i C:\MagtekCC\Files\Java\jre1.8.0_144.msi" -wait /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log" 
     Write-Host -NoNewLine "Done.`n" -ForegroundColor Cyan
      Start-Sleep -s 2

> Start-Process : A positional parameter cannot be found that accepts argument '/QN'.
At line:1 char:1

    + start-process msiexec.exe  "/i C:\MagtekCC\Files\Java\jre1.8.0_144.ms ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : InvalidArgument: (:) [Start-Process], ParameterBindingException
        + FullyQualifiedErrorId : PositionalParameterNotFound,Microsoft.PowerShell.Commands.StartProcessCommand

推荐答案

msiexec.exe 的不寻常之处在于，虽然它具有广泛的 CLI(命令行界面)和许多受支持的参数，但它是一个 GUI 子系统可执行文件，独立于任何调用控制台运行.

msiexec.exe is unusual in that, while it has an extensive CLI (command-line interface) with many supported parameters, it is a GUI-subsystem executable that runs independently of any calling console.

PowerShell 在您直接调用它们时异步运行它们；也就是说，与控制台子系统可执行文件不同，它在继续之前不等待可执行文件终止.

PowerShell runs GUI-subsystem executables asynchronously when you invoke them directly; that is, unlike with console-subsystem executables, it doesn't wait for the executable to terminate before continuing.

虽然Start-Process -Wait 确实是同步调用 GUI 子系统可执行文件的典型方式，有也是一个方便的快捷方式:

While Start-Process -Wait is indeed the typical way to invoke a GUI-subsystem executable synchronously, there is also a convenient shortcut:

如果您管道到写-输出:^[1]

• PowerShell 将等待可执行文件(的进程)终止，即使它是一个 GUI 子系统应用程序.

• PowerShell will wait for the executable('s process) to terminate, even if it is a GUI-subsystem application.

• 注意:如果您知道 GUI 应用程序没有标准输出 - 并且不这样做是典型的 - 您也可以通过管道Wait- 处理以获得更好的概念清晰度(再次参见脚注 [1]).

• Note: If you know that the GUI application produces no stdout output - and not doing so is typical - you can also pipe to Wait-Process for better conceptual clarity (again, see footnote [1]).

此外，自动$LASTEXITCODE 变量 将正确反映进程的退出代码(没有多少GUI-子系统可执行文件有意义地设置，但是misexec.exe)，允许您推断成功(退出代码0)与失败(任何非零退出代码)，按照惯例.

Additionally, the automatic $LASTEXITCODE variable will properly reflect the process' exit code (which not many GUI-subsystem executables meaningfully set, but misexec.exe does), allowing you to infer success (exit code 0) vs. failure (any nonzero exit code), by convention.

因此，您可以使用以下内容:

Therefore, you can use the following:

# Note the `| Write-Output` at the end of the line, which ensures *synchronous* execution.
msiexec.exe /i "C:\MagtekCC\Files\Java\jre1.8.0_144.msi" /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log" | Write-Output
$exitCode = $LASTEXITCODE

Write-Host -ForegroundColor Cyan "Installation finished with exit code $exitCode."

以上是以下 Start-Process -Wait 解决方案的更方便的替代方案，它也使用 -PassThru 来传递代表已启动进程的对象，因此可以检查其 .ExitCode 属性:

The above is the more convenient alternative to the following Start-Process -Wait solution, which also uses -PassThru to pass an object representing the launched process through, so that its .ExitCode property can be checked:

$exitCode = (Start-Process -Wait -NoNewWindow -PassThru msiexec.exe @'
/i "C:\MagtekCC\Files\Java\jre1.8.0_144.msi" /QN TRANSFORMS="jre1.8.0_144.mst" /L*V "C:\Temp\msilog.log"
'@).ExitCode

Write-Host -ForegroundColor Cyan "Installation finished with exit code $exitCode."

^{注意:-NoNewWindow 在这种情况下通常没有区别，但会允许那些显式附加到调用者控制台的罕见 GUI 应用程序的控制台输出(参见脚注 [1])到当前控制台中的表面 - 尽管无法捕获它.}

^{Note: -NoNewWindow typically makes no difference in this case, but would allow console output from those rare GUI applications that explicitly attach to the caller's console (see footnote [1]) to surface in the current console - albeit without the ability to capture it.}

注意misexex.exe的所有参数如何作为单个字符串传递给Start-Process代码>(使用 here-string 用于此处的可读性)，它在位置上绑定到 -ArgumentList 参数.

Note how all arguments for misexex.exe are passed as a single string to Start-Process (using a here-string for readability here), which positionally binds to the -ArgumentList parameter.

虽然 -ArgumentList 参数在技术上接受一个 array 参数 - 即允许您单独传递参数 - 一个长期存在的错误使这是不可取的 - 请参阅这个答案.

While the -ArgumentList parameter technically accepts an array of arguments - i.e. allows you to pass arguments individually - a long-standing bugs makes that unadvisable - see this answer.

至于你尝试了什么:

您的 Start-Process -Wait 调用失败，因为您最终传递了两个以上位置参数:

Your Start-Process -Wait call failed, because you ended up passing more than two positional arguments:

start-process msiexec.exe  "/i ..." -wait /QN ...

• msiexec.exe 在位置上绑定到 -FilePath 参数.
• 只有 "/i ..." 参数在位置上参数绑定到 -ArgumentList 参数.
• 由于没有其他 Start-Process 参数支持位置绑定，Start-Process 不知道如何处理 /QN(并且所有后续位置(未命名)参数)，这就是您问题中的错误消息所指示的内容.
• msiexec.exe positionally binds to the -FilePath parameter.
• Only the "/i ..." argument positionally argument binds to the -ArgumentList parameter.
• Since no other Start-Process parameters support positional binding, Start-Process doesn't know what to do with /QN (and all subsequent positional (unnamed) arguments), which is what the error message in your question indicates.

注意:如果您确实想单独传递参数 - 最好避免，如上所述 - 您必须将它们作为数组传递，由,
(Start-Process -Wait msiexec.exe '/i', ...)

Note: If you did want to pass parameters individually - which is best avoided, as stated above - you'd have to pass them as an array, separated by ,
(Start-Process -Wait msiexec.exe '/i', ...)

^{[1] 注意后续管道段中的any命令是为了保证同步执行，因为PowerShell总是要等待前面段的命令终止，以确保已收到所有输入；虽然最终选择什么命令并不重要，但 Write-Output，在这种情况下 通常 是一个无操作，具有通过 stdout 输出传递的优势以便它变得可见/可以被捕获，如果手头的 GUI 应用程序产生这样的输出，这是罕见的(将 2>&1 附加到 GUI 应用程序调用还捕获stderr 输出).正如Bender the Greatest 指出的那样，一些GUI 应用程序这样做是为了产生调试输出，通过显式附加到调用者的控制台.}

^{[1] Note that any command in a subsequent pipeline segment works to ensure synchronous execution, because PowerShell always has to wait for the preceding segment's command to terminate, so as to ensure that all input has been received; While it ultimately doesn't matter what command you choose, Write-Output, which in this case will typically be a no-op, has the advantage of passing stdout output through so that it becomes visible / can be captured, if the GUI application at hand produces such output, which is rare (append 2>&1 to the GUI-application call to also capture stderr output). As Bender the Greatest points out, some GUI applications do so in order to produce debugging output, by explicitly attaching to the caller's console.}

这篇关于Java MSI 静默安装程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！