Question

我已经定义了以下非常基本的WIX 3.11捆绑包，并且我已经删除了在安装MSI之前触发的execpackage，因为我将要描述的问题只发生在MSIPackage命令和特定的第三个派对MSI我正在使用。

<?xml version="1.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
        xmlns:bal="http://schemas.microsoft.com/wix/BalExtension">
  <Bundle Name="ACME APP 32Bit" Manufacturer="ACME CORP" Version="1.0.0.0" UpgradeCode="0B736949-AE50-46B0-A534-42C9672FAF1F" IconSourceFile='..\Common Files\Images\icon.ico'>
    <BootstrapperApplicationRef Id="WixStandardBootstrapperApplication.RtfLargeLicense">
      <bal:WixStandardBootstrapperApplication
        LicenseFile="..\Common Files\Documents\EULA.rtf"
        ShowVersion="yes"
        LogoFile="..\Common Files\Images\logo-64x64.png"    
        LogoSideFile="..\Common Files\Images\logo-64x64.png" 
        />  
    </BootstrapperApplicationRef>
    <Chain>
        <MsiPackage Id="TP32BIT" SourceFile="ThirdParty.msi" Visible="no" />

    </Chain>
  </Bundle>
</Wix>

在捆绑部署MSI并且安装成功完成对话框出现之后，再次发生修改设置对话框（修复卸载取消）。

这似乎只发生在我需要安装的第三方MSI上。我无法控制此MSI，此时我也无法获得制造商的更换支持。

我已经用另一个随机产品替换了MSI，但它并没有导致同样的问题。它的部署没有有效地再次尝试运行捆绑安装程序。

我已经从命令行运行第三方MSI，并在滴注时检查了它的返回码并返回0.

我感到困惑的是，导致安装程序认为在完成此MSI后需要再次运行自己。非UUID没有冲突，我不认为我的xml中有任何错误。

如果有人能说清楚这一点，我会很感激。目前我唯一能想到的就是尝试通过从命令行运行msiexec的execpackage方法将这个特定的MSI部署到平台，但这完全否定了我首先使用bundle的原因。 / p>

提前致谢。

Answer 1

读这篇文章我有点困惑。

如果您使用Burn Bundle之外的完整设置GUI以交互方式运行ThirdParty.msi，问题是否会显现？
换句话说，常规安装，不是通过命令行调用，而是通过双击MSI >然后单击设置GUI运行。

我认为设置完成对话框中的某些奇特事件可能会启动一个疯狂的自定义操作。这是我们可以看一看的MSI吗？你能提供下载地点吗？（虽然没有承诺）。

当设置以静默模式运行时，GUI序列不会运行 - 这可以解释为什么事情在静默模式下工作 - 如果确实如此。

Answer 2

原来这是由第三方MSI触发的WIX中的已知错误。 github.com/wixtoolset/issues/issues/5266此MSI无法更改，必须使用此机制部署其内容。我已经能够创建一个解决问题的工作，因为安装程序在MSI完成后启动了2个新的Wix实例，所以我正在跟踪进程ID并杀死任何“未知” -

Wix Installer：捆绑的MsiPackage导致安装捆绑包尝试再次运行？

2 个答案: