我几乎已经将install4j作为我项目的首选安装包。在众多其他优势中，据我所知，它内置支持Upgrades out-class the field。我确实有一个奇怪的问题..
是否有最佳实践或任何可重复使用的代码来支持“bootstrapping”install4j安装程序的概念及其需要支持的任何元数据升级使用“自行增长”安装机制安装的产品的旧版本？
与我所假设的许多项目一样，我们的项目已经存在多年，并且有针对Windows的InstallShield安装程序和适用于Unix的BASH脚本的混搭。我们正在使用install4j来整合所有这些。
一些可能有趣的后续问题可能是： 1.有没有办法可以在API中设置从isUpgradeInstallation（）返回的值？ 2.如果我将文件放在.install4j目录中，并且我的新安装程序中嵌入了应用程序ID，那么install4j可以用它运行吗？
非常感谢任何想法/指示。
答案 0 :(得分：2)
通常您会添加自定义逻辑来处理旧版升级的情况。
但是，您可以通过在包含i4jparams.conf文件的旧安装目录中创建.install4j目录，将旧版安装转换为“假”install4j安装。在该伪配置文件中，唯一重要的信息是版本信息和应用程序ID，您可以删除其他所有内容。
然后context.isUpdateInstallation()将返回true。