Is it possible to bundle an add on update installer within a main installer and detect if there is a previous version present on the machine = run the add on update installer else run the main installation?
I don't think it would make a lot of sense to bundle a separate update installer. Also, an add-on installer cannot perform an update since it cannot change the installed version.
Installers know if they are performing an update or not and you can change their behavior based on that condition.
For example, in order to not execute a particular action for an update, set its condition expression to
!context.isUpdateInstallation()
If you have complex update-dependent logic for file installations, you can handle that in the "File filter" property of the "Install files" action.
Related
We have an installer with a separately selectable auto-update feature.
Normally, if a customer wants to switch that feature on or off after the installation has completed, we tell them to re-run the installer and correct the setting. (Tested, works.)
Now a customer has a problem: Their corporate IT prepared an installation package that (mistakenly) has auto-update installed, and said IT refuses to put out a corrected installation package.
So the question is:
Can I give the customer a reasonably future-safe way to disable auto-update - say, by modifying a registry entry - without having to re-run the installer?
On Windows, the registry key
HKEY_CURRENT_USER\SOFTWARE\ej-technologies\install4j\installations
contains values with the names updateSchedule<application id>. If you locate the one for your installer, you can change the value data to "never".
For each installation I would like to introduce the current version on the welcome screen. For that, I create a "Read a properties file" action which reads my application manifest.properties which exists under the distribution tree. A step later I have a "Run script" action which extracts the properties I need for the version and set it into installer variables.
My problem is that when trying to install the installer on a clean computer it throws an error since it has no distribution tree nor the manifest.properties.
Is there any elegant way to set the variables before the installation process begins, like in the build time for example?
The version of your application is configured on the "General Settings->Application Info" step. You can use it in all text properties with this syntax:
${compiler:sys.version}
I want to create an upgrade setup. I have an old setup with for example version 1.0.1.43 and my new setup will has version of 1.0.1.45
I have created a new basic MSI project in installshield. I set version to 1.0.1.45 I copied both product code and upgrade code of old setup into upgrade setup. I also added all of new files in setup that should be replaced with files of old setup. I selected all files and then right clicked on them and in properties checked always overwrite option. then in Media section I added a major upgrade with upgrade code of my old setup. then I build the setup.
when I run this setup it shows me that you have installed this application do you want to upgrade it or not? then I choose yes to upgrade. after installing this setup I figured it out that in add/or remove programs version of my application has changed to 1.0.1.45, that means it has been upgraded. but when I check files I see that none of new files has been replaced with new one.
Where am I wrong that this setup ignore all of my new files to replace? I want this setup find old path of old setup and after removing all files, add new files to that path?
thanks
As you are saying, you have created new MSI installer for upgrade. So in this case the component ID of components in which your files are present, got change. So you need to set values of Component ID with the component IDs of your installer 1.0.1.45. Or you need to create different components with the same target path.
Also you can validate your upgrade build 1.0.1.46 with the main build 1.0.1.45 with following steps.
Build Menu -> Validate -> Upgrade Validation Wizard
Then give path of your main installer (msi/exe) and your upgrade installer (msi/exe). And check what differences both builds are having.
I have an installer whose purpose is updating the max version of a JDK for an existing installation (we require JDK, not JRE), and pointing the existing installation to run with the later version of the JDK (which is user pre-installed and user-specified).
In the installer, I have code that calls JVM.setPreferredJVM() from a directory chooser form component. According to the API for JVMSelector, it says this method will "Set the preferred JRE/JDK for your application." According to the help docs on variables (sys.preferredJRE), "This variable will only be set after the "Install files" action has run."
When I run the installer, I see that the setPreferredJVM() method is called, but the sys.preferredJRE is not set to what I wanted, it still references the old JVM. This is a problem because my subsequent "Add VM Options" steps use the sys.preferredJRE variable.
I expected that calling JVMSelector.setPreferredJVM() would update sys.preferredJRE, but it does not. How can I accomplish this so that the user can set the preferred JVM/JDK during the install?
This is a bug, it will be fixed in 6.0.2. Please contact support#ej-technologies.com to get an interim build with the fix.
We have an eclipse feature that is licensed and the license is handled by our own code. The user can go in on our update-site and upgrade his feature. The problem we face is when the user's license needs to be updated before he can use the new upgrade.
What I want to do is to validate the feature version against the users license and warn the user that his license needs to be updated before he install.
I thought I would do this using a custom eclipse p2 touchPoint action validateLicense.
Example:
My code is called, where I validate the version against the user's license. If it fails I warn the user and he can then cancel the installation.
So my first question is:
Do I get this right, or is it some other way to do this?
My second question is pretty basic:
Where do I tell eclipse to run my code?
I have looked here at eclipse help where they explain what it is. But I don't understand where to put the information to run my code? Is it in the feature.xml.
Lastly:
Is there an example how to create and use p2 touchPonts?
I implemented a custom action as shown here and I have a system that seems to work. I left out "touchpoint" extension as it's unnecessary in my case, but the rest is the same.
My action is executed during install phase of my feature (instructions.install) but maybe configure phase could work too. Collect phase did not work.
The action is executed during installation process, after the download was already performed. Ideally it would be before the download but it's not a big issue for me. Returning an error status from the action cancels the install. It leaves some downloaded files around but they do not get activated and are probably removed later by p2's garbage collector.
I also managed to do some more interesting things. My actions plugin has a dependency (optional and non-greedy) on my main plugin. So the install works like this:
Actions plugin is downloaded
Custom action is executed
The action detects whether my main plugin is already installed and if yes, it calls into it to retrieve licensing info. The main plugin has to expose an API for the action. The action also checks main plugin's version to detect whether the API is there or not.
The action now can decide whether to proceed or cancel the install. It can even interact with the user using Display#syncExec (this is what the code in checkTrust phase does so I think it's safe). If needed, the action could also detect whether the install is headless.
Some gotchas:
Action itself must be versioned. It's the version you declare in plugin.xml and p2.inf files and it's different from plugin's version. I just replace 1.0.0 with the same version my plugin has. This way the latest version of the action plugin is always downloaded before being executed. This is great because now any problem changes to licensing rules can be implemented in actions plugin.
Actions API changed between Eclipse 3.5 and 3.6. I will probably drop support for 3.5 as it's pretty old anyway.
Actions plugin should probably be signed. It's the case in my case. The system seems almost too powerful to me as just pointing Eclipse to an update site gets it to execute downloaded code.
I still need to test how this works with different versions of Eclipse and other IDEs. I saw a strange (non-blocking) error with 3.6. However the results are promising and it looks like the system might actually work.
Touchpoints are executed at installation time, which means that the resolution (validation) has already happened. I'm not sure they would help. What about creating an Installable Unit (IU) (or Eclipse Feature) that represents the license the user has installed. Then you would put a dependency from your product to that license.
For example, create an IU called com.mycompany.license (1.0.0). You would create another one called com.mycompany.license (2.0.0). When you installed a license, the appropriate IU would be added to the profile.
Now, when you go to install you product, the new version of the product would require license version 2.0.0. If this license was not installed, the resolution would fail.
Does this make sense? Do you think this would help?