WiX安装程序FileSearch获取完整文件路径

Question

我正在使用WiX创建MSI，并且该MSI接受用户输入的属性，即安装程序逻辑将使用的文件名路径。我试图通过确定该文件是否存在来验证该属性，但是由于具有完整文件路径，我无法弄清楚如何使其与DirectorySearch和FileSearch模式协作。

所以，假设用户运行了如下MSI： msiexec /i myinstaller.msi CUSTOMFILE="C:\test\input.txt" 那么，我需要运行类似以下命令：

<Property Id="CUSTOMFILEEXISTS">
  <DirectorySearch 
    Id="LocationConfigDirSearch" 
    Path="[CUSTOMFILE_DIR]" Depth="0">

    <FileSearch Name="[CUSTOMFILE_FILENAME]"></FileSearch>
  </DirectorySearch>
</Property>

但我:

1. 无法弄清如何将文件名拆分为其各个部分。像 Path.GetDirectory([CUSTOMFILE]) 和 Path.GetFileName([CUSTOMFILE]) 这样的函数最理想。或者;
2. 无法确定使用完整文件名是否存在该文件。例如，DirectorySearch 中是否有一个属性 IgnoreFileName="true"，但我知道这种属性不存在。

我是否需要编写扩展代码或自定义操作？我希望这是一个足够简单的需求，不需要走那么远。

- Snixtor

---

让所有这些变得更简单的另一种方法是不在安装程序中进行配置。你能否将其推迟到应用程序首次运行时？但并非总是可行。 - Christopher Painter

我们需要知道input.txt文件里面有什么。 - Stein Åsmul

不仅如此，还要考虑应用程序的类型。例如，“首次运行”对于Windows服务来说并不适用。 - Christopher Painter

Answer 1

FileSearch元素是Windows Installer中Signature表的一个抽象。FileName列不支持Formatted数据类型，因此您无法在该属性中放置属性。

您可以尝试标准化固定文件名，并要求用户提供目录路径而不是文件路径的属性。然后，我认为您可以使用AppSearch在该目录中查找文件，而无需编写自定义操作。

否则，进行简单发现而不进行任何状态更改的自定义操作并不是世界上最糟糕的事情。只要注意不引入任何主机脆弱性即可。Windows Installer中的ActiveScript（VB/JScript）支持极易出现问题。我认为C#/DTF托管自定义操作是可接受的，但并非每个人都这样认为。这留下了C/C++，它可以非常稳定，但编码难度较大。这是一个简单的CA，因此应该很容易理解。

- Christopher Painter

---

虽然这并没有给情况带来任何新的想法，但对选项的合理评估足以让我接受它作为答案。对于FileSearch元素的内部工作细节也非常感激。指出ActiveScript自定义操作的危险性也是明智之举。 - Snixtor

Answer 2

检查不对目标系统进行任何更改的操作实际上可以通过自定义动作VBScript来执行。只要没有系统更改，就不需要回滚功能，而且脚本通常比复杂的文件搜索机制更容易使用。只需确保脚本简单，并进行充分测试。

一个值得思考的问题是这个文本文件里面有什么内容，以及如何在安装会话中指定它。您是通过命令行传递它，还是有一个浏览对话框来指定路径？

这里只是一个简单的检查文件脚本，来自脚本库：

Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FileExists("C:\FSO\ScriptLog.txt") Then
    Set objFolder = objFSO.GetFile("C:\FSO\ScriptLog.txt")
Else
    'Wscript.Echo "File does not exist."
End If

请注意，我认为您无法在VBScript自定义操作中调用Wscript。但是，在立即模式下，您将可以访问MSI文件的Session对象。延迟模式访问比较困难，如此处所述，但这有点超出了您所指示的用途范围。

- Stein Åsmul

---

抱歉，脚本自定义操作永远不是好的选择。确实，您不必处理事务状态更改的复杂性，但我无法告诉您有多少次我看到脚本自定义操作失败，就像Rob所说的那样，或者是因为FileSystemObject已损坏。请不要尝试这样做。http://blogs.msdn.com/b/robmen/archive/2004/05/20/136530.aspx - Christopher Painter

这不准确 - 简单的只读VBScript自定义操作可以正常工作。我们在大公司中一直使用它们进行重新打包。尽管这是标准操作环境，但它与任何其他机器一样容易出错。您自己推荐.NET自定义操作 - 非常容易出错，并且它们同样依赖于未损坏的系统？我通常会使用C ++进行高配置文件设置，以处理大量具有读写代码的机器。此脚本仅用于检查。 - Stein Åsmul

这并不是那么清晰明了。这是一个只读文件检查脚本。它在系统上没有做任何事情，即使在高级设置中，我也会接受它的使用。VBScript 也是透明的，甚至可以意味着您的软件更容易被企业接受。没有狂热主义或粉丝主义应该决定，只有理性思考和利弊评估。一个简单的 cab 提取可能会触发反病毒问题，但我们仍然使用它们。 - Stein Åsmul

让我补充一下，我反对使用任何脚本或自定义操作来执行那些可以通过标准MSI机制更轻松、更可靠地实现的操作。然而，脚本可以用于检查系统、设置属性和进行只读操作等任务。我从来没有在使用这样的脚本时遇到过问题。 - Stein Åsmul

别让我开始谈CAB文件和反病毒软件...而你还使用VBScript并提取CABS。唉... - Christopher Painter

Answer 3

如果不运行自定义操作来显式搜索系统，无论使用哪种语言，另一个选择是编写代码在正在运行的MSI文件中创建自己的AppSearch。关键是将文件添加到Path表中的DrLocator表中。当然，在AppSearch之前要这样做。

我认为说该文件必须具有固定名称并位于MSI文件旁边或用户的AppDataFolder等位置不会成为大问题，然后您可以根据[SourceDir]或[AppDataFolder]对特定文件进行AppSearch

这是一个静默安装吗？是否有理由不能添加自定义对话框以浏览文件？

- PhilDW