在我的 WIX 项目中，我有一个类似这样的目录结构：
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="INSTALLLOCATION" Name="FolderName">
...
</Directory>
<Directory Id="MYDIRECTORY" Name="SomeDifferentDirectory">
...
</Directory>
</Directory>
这里INSTALLLOCATION代表我的程序的安装文件夹，但是我想另外创建一个安装目录之外的目录，例如D:\MyFolder1\MyFolder2，从上面的示例中，我如何分配这个值MYDIRECTORY以便在安装完成后创建它？
我没有时间测试我在下面列出的选项，但它们应该是可行的，技术上的可能性。希望其中一种选择是令人满意的。
但是，首先：我不喜欢这种设置二级、顶级目录的方法——真的需要吗？你能解释一下这个场景吗？也许有更可靠的方法？
请参阅底部的“替代方案？ ”部分，了解我认为比“摆弄”目录属性更好的方法。如果我是你，我会读这个“替代品？” 第一部分 - 也许它可以为您节省很多麻烦？
但第一部分涉及各种技术选项来满足您的要求：
有很多方法可以设置目录属性，我想不到。正如我所说，我没有时间测试这些选项 - 发布未经测试的建议总是很疯狂，但您似乎可以帮助自己提供一些建议：
[ROOTDRIVE]MyFolder.
[WindowsVolume]MyFolder- 可能确实有效，但我个人并不喜欢它。首先，我不想将任何内容安装到系统驱动器上的顶级文件夹中。SetDirectory Element这个“设置属性”的目的。我认为它可以为您完成所有自定义操作。一些自动魔法。但是，我不确定此功能是否允许从命令行覆盖公共属性？D:\MyFolder则必须注意此路径可能会在某些时候意外丢失（从系统中删除驱动器、添加新驱动器 (?)、添加新 DVD 驱动器 (?)、手动更改驱动器号等... ）。
PersonalFolder（我的文档），然后将其重定向到 Windows 本身的 D:\。PersonalFolder如果在启动时找不到它，我相信 Windows 会为其分配一个新值。然后，Windows Installer 将仍然能够枚举目标文件夹，而不仅仅是卡住或崩溃。将目录设置为安装程序 GUI 的自定义对话框中公开的功能目录。
ConfigurableDirectory属性设置为FeatureElement等于保存目录路径的 PUBLICPROPERTY。<UIRef Id="WixUI_Mondo" />) - 从“自定义”对话框中，您现在应该能够从 WiX GUI 设置此目录。这里有一个使用 Visual Studio 更新 WiX 源文件以使用 Mondo 的分步示例：WiX 安装程序 msi not installed the Winform app created with Visual Studio 2017。ConfigurableDirectory为该功能指定的属性。一个常规的即时模式自定义操作（不是设置属性自定义操作），它通过在代码中某处调用Session.Property = "SomeValue" 来设置属性。每种类型的自定义动作类型对“属性集”的执行方式略有不同（自定义动作类型：VBScript、C++、DTF / C# 等...有关如何执行此操作，请参阅 Advanced Installer 的文档）。
有些人甚至在属性表中硬编码路径，或者使用设置属性自定义操作C:\在运行时分配给属性 - 完全不可接受。这将打破- 这只是时间问题。在没有 C:\ 驱动器的计算机上，它根本不会安装 - 对于初学者。
不确定是否会在属性表中设置这样的属性，directory resolution并且costing- 我从来没有尝试过 - 这不是一个解决方案，我只想声明以防止它的使用。
设置属性自定义操作分配C:\或类似于属性将看起来有效，但会以意想不到的方式爆炸。保证。
再说一遍：如果可以，请不要部署到单独的顶级文件夹。
我听说有些人——在公司的标准化环境中——使用环境变量来定义这样的安装文件夹。我从未将其用于生产，从未尝试将其用于测试，也不喜欢将其作为选项。
请记住，公共属性可以在命令提示符处设置 - 因此可能会覆盖您添加的任何逻辑以自行设置。也许添加一个自定义操作来检查来自命令行的值，如果它是错误的，要么接受它，要么中止设置。
这是具有可配置功能目录的 WiX 安装程序的 GUI 屏幕截图：
上面看到的浏览按钮仅适用于具有ConfigurableDirectory指向自定义目录属性的指定属性的功能（忽略C:\上面屏幕截图中的条目 - 只是打嗝）：
<!-- A standard feature -->
<Feature Id="ProductFeature" Title="MinimalShortcutTester" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
<!-- A configurable directory feature -->
<Feature Id="FeatureDirectory" Title="FeatureDirectory" ConfigurableDirectory="MYCUSTOMDIR">
<!-- your stuff here -->
</Feature>
在 WiX 源代码的其他地方，实际的可配置目录：
<Directory Id="MYCUSTOMDIR">
<!-- Mock-up GUID that MUST be changed, custom target directories do not function with auto-GUIDs -->
<Component Id="MyFile.exe" Guid="{00000000-0000-0000-0000-000000000000}" Feature="FeatureDirectory">
<File Source="C:\SourceControl\MyFile.exe" />
</Component>
</Directory>
我会使用一个额外的自定义操作来MYCUSTOMDIR很好地默认这个目录，或者检查用户所做的选择是否有效。这并不完全直截了当，但必须在每种情况下处理。
再想一想，我可能会使用 aset property custom action将 MYCUSTOMDIR 目录默认为 的子文件夹PersonalFolder，然后允许用户在安装时覆盖它。现在您必须回读用户选择的修改和修复（以及其他安装模式），否则您将默认使用PersonalFolder您在其他安装模式中指定的任何子文件夹。您可以将用户文件夹选择保留在注册表中，然后使用AppSearch（我认为大多数专业人士的偏好）将其读回，或者在自定义操作中完成所有操作。在所有安装模式下使这项工作正常工作可能具有挑战性。好好测试。
技术挑战：如果您将原始文件夹选择保留MYCUSTOMDIR在注册表中并使用 回读，则AppSearch必须确保设置您的设置属性自定义操作（用于将默认值设置为MYCUSTOMDIR如果没有设置值），以便如果属性已经具有从注册表检索的值，则它不会运行。不是火箭科学，但可以很巧妙地做到正确 - 并且在所有安装模式下进行测试。如果您依赖标准结构而不是自定义操作，那么一旦您了解所涉及的“移动部件”，您通常会受益 - 首先您默认首次安装，因为尚未设置任何值（除非通过命令行设置值），然后您允许它在 GUI 中（或通过命令行）被覆盖，然后在安装过程中保留在注册表中，在下次启动（修复、修改、自我修复、升级、补丁）时，您读回保留的值并且不要让通过条件等设置默认值...
提供一个安全链接：Wix : Disable control in built-in dialog。
如上所述，这些二级顶级目录层次结构通常可以通过更好地理解替代方案来避免。
检查替代方案的一些问题：