Wix 安装程序在具有管理员权限的命令行上使用错误的路径 [英] Wix Installer Going to Wrong Path on Command Line with Admin Privilege

问题描述

我在 Wix 中构建了一个简单的安装程序，它将在预先存在的产品安装中的特定文件夹中放置几个​​数据文件，以便用户无需了解有关产品安装的任何信息即可更新他们的数据文件.该产品将其安装路径存储在一个环境变量 (ENVVAR) 中，我在这里使用它来计算其 NewData 子文件夹的路径.

I built a simple installer in Wix which will place a couple of data files in a specific folder in a preexisting product installation so that the user doesn't need to know anything about the product's installation in order to update their data files. The product stores its installation path in an environment variable (ENVVAR) which I'm using here to calculate the path of its NewData subfolder.

当我双击 .msi 或从命令行 (msiexec/i filename.msi) 运行它时，它运行良好，文件显示在 C:\ProductPath\新数据.但是，如果它是使用提升的权限(msiexec/a filename.msi)安装的，则文件会转到 D:\ 的根目录(甚至不是同一个驱动器)产品已安装.)

When I double-click the .msi or run it from the command line (msiexec /i filename.msi) it works perfectly and the files show up in C:\ProductPath\NewData. However, if it's installed with elevated privileges (msiexec /a filename.msi) the files go to the root of D:\ (which isn't even the same drive the product is installed on.)

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"
     xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension">

  <?include InstallVariables.wxi ?>

  <Product Id="*"
           Name="Product Name"
           Manufacturer="My Company"
           Version="$(var.Version)"
           UpgradeCode="guidgoeshere"
           Language="1033">

    <Package Description="Description $(var.Version)" Comments="Install package for my product."
             InstallerVersion="300" Compressed="yes" InstallScope="perMachine"/>

    <Media Id="1" Cabinet="Cabname.cab" EmbedCab="yes" CompressionLevel="high"/>

    <SetDirectory Id="PATHMAP" Value="[%ENVVAR]\NewData" Sequence="first"  />

    <!-- Describe the folder layout here. -->
    <Directory Id="TARGETDIR" Name="SourceDir">
      <Directory Id="PATHMAP" FileSource="..\New Files">
        <Component Id="File1" Guid="guidgoeshere">
          <RemoveFile Id="Remove_File1File" Name="$(var.File1Pattern)" On="both" />
          <File Id="File1File" Name="$(var.File1)" Vital="yes" KeyPath="yes" />
        </Component>
        <Component Id="File2" Guid="guidgoeshere">
          <RemoveFile Id="Remove_File2File" Name="$(var.File2Pattern)" On="both" />
          <File Id="File2File" Name="$(var.File2)" Vital="yes" KeyPath="yes" />
        </Component>
      </Directory>
    </Directory>

    <Feature Id="FeatureId" Title="New Files for a Feature" Level="1" >
      <ComponentRef Id="File1"/>
      <ComponentRef Id="File2"/>
    </Feature>

  </Product>
</Wix>

注意组件中的文件删除是故意的；如果存在任一文件的现有版本(文件名可能略有不同——不是我的选择)，我想删除并替换它.用于执行此操作的模式位于包含文件中并且可以正常工作.

Note that the file removal in the components is intentional; if there is an existing version of either file (which may have a slightly different file name -- not my choice) I want to remove and replace it. The patterns used to do so are in the include file and are working properly.

推荐答案

命令行:msiexec.exe/a filename.msi 不会触发具有提升权限的安装，而是管理安装.按照描述的链接 - 完成描述很重要.本质上，管理安装只是提取 MSI 中的嵌入文件以制作网络安装映像，人们可以从中运行 MSI 的常规安装(在上面的链接答案中有更好的解释) - 管理安装不安装什么都没有 - 这只是提取.

The command line: msiexec.exe /a filename.msi will not trigger installation with elevated privileges, but rather an administrative installation. Follow the link for a description - it is important that you do for a complete description. Essentially an administrative installation is just an extraction of embedded files in the MSI to make a network installation image from where people can run a regular installation of the MSI (better explained in the linked answer above) - administrative installations don't install anything at all - it is a mere extraction.

您应该能够通过提供如下 TARGETDIR 来控制管理安装的输出目录:msiexec.exe/a filename.msi TARGETDIR=C:\MyOutputFolder\.您的 MSI 可能缺少基本的 GUI 来显示管理安装的对话序列 - 这使得提取无需指定任何参数(因此默认情况下您输出到框中最大的驱动器).您可能需要考虑为您的 MSI 链接标准对话框集，例如 <UIRef Id="WixUI_Mondo"/>.您可以在此处查看有关如何执行此操作的分步说明:WiX 安装程序 msi 未安装使用 Visual Studio 2017 创建的 Winform 应用.这将为您的安装提供基本的标准 GUI，用于常规安装和管理安装.我认为非常有用 - 您还应该设置自己的许可协议 - 我已经更新了链接的答案以包含该内容.

You should be able to control the output directory of the administrative installation by providing a TARGETDIR like this: msiexec.exe /a filename.msi TARGETDIR=C:\MyOutputFolder\. Your MSI is probably lacking a basic GUI to show the administrative installation's dialog sequence - which makes the extraction happen without any parameters specified (hence you output to the largest drive on the box by default). You might want to consider linking a standard dialog set such as <UIRef Id="WixUI_Mondo" /> for your MSI. You can see a step-by-step description of how to do this here: WiX installer msi not installing the Winform app created with Visual Studio 2017. This will give your setup basic, standard GUI for both regular installation and administrative installation. Very useful I think - you should also set your own license agreement - I have updated the linked answer to include that.

我认为这是您的答案的结尾.使用/a 安装并不是使用提升的权限进行安装 - 本质上 - 它只是提取文件.但是请在默认 GUI 中进行链接，以使您的 MSI 更加标准和整体更好.

I think this is the end of the answer for you. Installing with /a isn't installation with elevated rights - essentially - it is just an extraction of files. But do link in that default GUI to make your MSI more standard and better overall.

关于环境变量方法的一些评论.我从来没有在环境变量中存储过这样的东西.我通常只是写到我自己在 HKLM 中的位置，然后通过自定义操作或使用 MSI 的内置搜索功能从那里读回(最好是后者 - 依靠内置的 MSI 功能要好得多.我有点草率有时使用只读自定义操作，但非常反对读写自定义操作.您可以在这里了解原因:为什么在我的 WiX 中限制自定义操作的使用是个好主意/MSI 设置? - 我猜是题外话).WiX 可以轻松定义这些搜索并将搜索结果设置为您的属性:Define Searches Using变量.

A couple of comments on the environment variable approach. I have never stored anything like that in environment variables. I usually just write to my own location in HKLM and read back from there either via a custom action or using MSI's built in search feature (preferably the latter - it is much better to rely on built-in MSI features. I am a little sloppy with read-only custom actions at times, but very much against read-write custom actions. You can see why here: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups? - a digression I guess). WiX can easily define these searches and set the search result to your property: Define Searches Using Variables.

也许是WiX 工具集的记住属性"模式"，作者是 Rob Mensching(WiX 的创建者).这现在已经很老了，可能有一种新的、更聪明的方法来做到这一点，但我还不知道.

Maybe a quick link to "The WiX toolset's "Remember Property" pattern" by Rob Mensching (WiX creator). This is quite old now, there may be a new, smarter way to do this that I am not aware of yet.

如果我是你，我宁愿从网络下载这些更新的文件，而不是像这样使用 Windows Installer 将它们部署到数据文件夹"中.用户数据文件的部署一直是 MSI 的问题，其复杂的文件覆盖规则和怪癖".虽然可能与您的用例并不完全相关，但这里描述了您可以用来为应用程序部署数据文件的其他方法 - 也许以更可靠的方式:从管理员配置文件在当前用户配置文件上创建文件夹和文件.也许至少可以快速浏览一下.

If I were you, I would rather download these updated files from the network rather than deploy them like this into a "data folder" using Windows Installer. Deployment of user data files has always been problematic with MSI with its complex file overwrite rules and "quirks". Though perhaps not entirely related to your use case, here is a description of other approaches you can use to deploy data files for your application - perhaps in a more reliable fashion: Create folder and file on Current user profile, from Admin Profile. Maybe have a quick skim at least.

这篇关于Wix 安装程序在具有管理员权限的命令行上使用错误的路径的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！