0

我现在定义了以下非常基本的 WIX 3.11 捆绑包，并且我已经删除了在安装 MSI 之前触发的 execpackages，因为我要描述的问题仅发生在 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 部署到平台，但这完全否定了我首先使用捆绑包的原因。

提前致谢。

4

2 回答 2

0

读到这里我有点困惑。

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

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

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

于 2018-04-14T19:29:22.413 回答
0

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

于 2018-04-25T13:09:09.333 回答