InstallShield2010 XML 文件修改和卸载时的更改
我已经成功地获得了概念验证 MSI 安装程序，创建了一个 xml 文件，并在全新安装时按照我的意愿更新了元素。 我有 6 个功能，如果选择安装该功能，我希望为该功能创建一个节点，并根据属性设置一个属性。
如果我修改安装并删除以前安装的功能，我希望为其创建的 xml 节点持续存在并且我希望将我在安装时设置的属性设置为基于相同的属性进行更新（现在有不同的值）。
是否可以利用 InstallShield 的现有功能来做到这一点？看来我可以，并避免在删除功能时编写自定义操作来更新我的 xml。关于 isxmlcfg.dll 及其中的自定义操作似乎没有太多文档。
当我删除某个功能时，CA ISXmlUnInstall 正在运行 - 但似乎该操作所做的只是删除节点或保留它...
I've successfully got my proof of concept MSI installer creating an xml file, and updating the elements as I wish on a fresh install.
I have 6 features, if the feature is selected to be installed I want a node created for that feature and an attribute set based on a property.
If I modify the install and remove a feature previously installed, I want the xml node created for it to persist and I wish to set the attribute I set on install to be updated based on the same property (which now has a different value).
Is it possible to leverage InstallShield's existing functionality to do this? It seems I could, and avoid writing a custom action to update my xml when removing a feature. There doesn't seem to be much documentation on isxmlcfg.dll and the custom actions in it.
the CA ISXmlUnInstall is running when I remove a feature - but it appears all that action does is remove the node or leave it...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能遇到的问题是，尽管您在某些内容（例如注册表、ini 或 xml）中使用了该属性，但 Windows 安装程序本身并不将属性保留在其数据库中。你必须自己做这件事。因此，如果您想要进行修复、更改、升级或其他操作，并且想要拥有相同的属性数据，您不仅必须将其保存到某些内容（例如 xml ），而且还必须拥有相应的 AppSearch ( XmlSearch )可以将其拉回到属性中，以便它具有在 UI 期间显示的值和/或稍后写回 XML。
还可以考虑支持一种模式，仅当实际属性尚未具有值时，才将其读入临时属性并分配给实际属性。这样，某人就可以进行静默安装（升级）并传入该属性作为对先前配置的覆盖。 （搜索不会造成破坏）
The problem you are probably encountering is the fact that although you used the property in something ( say registery, ini or xml ) windows installer doesn't natively persist properties in it's database. You have to do this your self. So if you want to do a repair, change, upgrade or whatever and you want to have that same property data, not only do you have to save it to something ( say xml ) but you also have to have a corrosponding AppSearch ( XmlSearch ) that can pull it back into the property so it has a value to be shown during the UI and or writing back out to XML later.
Also consider supporting a pattern where it get's read into a temp property and assigned to the real property only if the real property doesn't already have a value. That way someone could be doing a silent install ( upgrade ) and pass in the property as an override to what was previously configured. ( No clobbering by the search )