Frank
Frank

Reputation: 165

How can I "bootstrap" an install4j Uprade installation of a non-install4j software install?

I've all but settled on install4j as my install package of choice for my project. Among many other advantages, it's built-in support for Upgrades out-classes the field as far as I can tell. I do have a curious question though ..

Is there a best practice or any reusable code for supporting the notion of "bootstrapping" an install4j installer with any metadata it needs to support Upgrading an older release of a product that was installed with "home grown" installation mechanisms?

As is the case with many projects I'd assume, ours is one that has been around for years and has a mishmash of InstallShield installers for Windows and BASH scripts for Unix. We're using install4j to consolidate all of that.

Some possible interesting follow-up questions might be: 1. Is there a way I can set the value returned from isUpgradeInstallation() in the API? 2. If I drop a file in a .install4j directory with the Application ID embedded in my new installer can install4j run with it?

Any ideas/pointers would be greatly appreciated.

Upvotes: 2

Views: 224

Answers (1)

Ingo Kegel
Ingo Kegel

Reputation: 47965

Usually you would add custom logic to handle the case of legacy upgrades.

However, you can convert your legacy installation to a "fake" install4j installation by creating an .install4j directory in the old installation directory containing an i4jparams.conf file. In that fake config file the only important information is the version information and the application ID, you can delete everything else.

Then context.isUpdateInstallation() will return true.

Upvotes: 2

Related Questions