WIX 解释器？
我需要描述部署/安装，可能还需要描述卸载 - 但我不想使用 Windows Installer。同时，我不想完全重新发明轮子。
我突然想到，我也许可以使用 WIX 声明性模式，但创建我自己的“WIX 解释器”，它将执行安装/卸载步骤（如目标 WIX xml 文档所述），而无需使用 Windows 安装程序。
如果能更进一步，我就能实现一个跨平台（Linux、MAC）的安装解释器了。当然，WIX 并没有考虑 Linux 和 MAC。在这种情况下，我要么添加 xml 命名空间来扩展 WIX，要么使用其他一些行业格式（我还不知道）。
但也许我太过分了。至少，拥有一个不会在 Windows 安装程序中创建任何记录的 WIX 解释器或 WIX 安装可执行文件会很好。它不需要满足 Windows 安装程序的所有功能。我只是希望看到一些基本功能得到实现。
有谁知道这样的事情，所以我可以省去自己做的努力？
I have a need to describe deployments/installs, and possibly uninstalls as well - but I don't want to use Windows Installer. At the same time, I don't want to completely re-invent the wheel.
It occurred to me that I could perhaps use the WIX declarative schema, but create my own "WIX interpreter" that will perform the install / uninstall steps (as described by a target WIX xml document) without using the windows installer.
It would be nice to go a step further, so that I achieve a cross-platform (Linux, MAC) installer-interpreter. Of course WIX did not have Linux and MAC in mind. In which case I either add xml namespaces to extend WIX, or use some other industry format (that I am yet unaware of).
But perhaps I'm stretching too far. At the very least it would be nice to have a WIX interpreter or a WIX install executable that does not create any records in the windows installer. It need not fulfill every capability of the windows installer. I'd just like to see some basic capabilities fulfilled.
Does anyone know of such a thing, so I can save myself the effort of making it myself?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
每个操作系统都有自己的管理已安装软件包的方法。
这意味着如果您实现自己的包管理方案，它将无法与当前操作系统标准很好地集成。这会带来许多非常糟糕的副作用，主要是通过标准工具维护操作系统的人员面临着不知道您的软件已安装的高风险，因为标准工具没有报告它已安装。
Microsoft 的安装程序与许多其他安装程序有很大不同，它支持通过编程进行扩展，这通常是用
VBC++ 语言完成的。此外，Microsoft 支持混合配置和安装，而许多其他包管理器将这些视为在不同时间执行的不同功能。最后，Microsoft 尝试在安装之前询问配置信息，而将配置和安装角色分开的安装程序通常要求在安装程序之后完成配置。事实上，关于安装的构成、何时/如何执行所述项目，以及在特定平台上可以使用哪些工具轻松地将“所有项目”合并到单个多系统安装工具中，存在太多不同的“假设”没有供应商进行一点协调以实现某些兼容性。
Each operating system has their own means of managing installed packages.
That means that if you implement your own package management scheme, it will not integrate well with the current operating system standard. This has a number of very bad side effects, mainly the people maintaining the operating system through standard tools run a high risk of not knowing your software was installed because the standard tool didn't report it was installed.
Microsoft's installer is quite different than many other installers, and it supports extension via programming, which is typically done in the
VBC++ language. Also, Microsoft supports the mixing of configuration and installation, while many other package managers see these as different functions to be performed at different times. Finally, Microsoft attempts to ask for the configuration information PRIOR to installation, while installers that separate out the role of configuration and installation typically request that the configuration be done AFTER the program is installed.In truth, there are way too many different "assumptions" about what constitutes installation, and when / how to do said items, and what tools can be expected on particular platforms to easily merge "all items" into a single multiple-system installation tool without the vendors coordinating a little bit to allow for some compatibility.