IzPack

Duplicate Entries in Add/Remove programs in windows

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 4.3.3
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows Registry problem
  • Number of attachments :
    0

Description

When a user installs a new version of my software over the top of a previous version they usually do so in the same directory. This causes duplicate entrys in the windows add/remove control panel, which results in a LOT of negitive feedback. Since they can not be removed without editing the registry.

There is a number of solutions to this and the simplest would seem to be allowing a check for a "previous" (I know you can already detect if the same version is installed) version then either disallow the install with a message, or even allow an unistall to kick of (I noticed the the CheckedHelloPanel does look for the uninstall string).

I see time and again questions about this very issue and the answer seems to be, "you should uninstall first", how about a mechinism to stop users who dont follow this convention, which in my experience is most of them.

If I get some free time and submit a patch is it likely to be included? I'm reluctent to make that kind of change then have to continually repatch Izpack each time it came out. Feedback on my suggestion, improvements, how to get it merged to the source, and other solutions would all be greatly appreaciated before I start work.

Thanks,
Tim

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Julien Ponge added a comment -

In such cases people may suffix the target install directory with the version number or something similar. Or you may change the registry keys, or something like that.

Show
Julien Ponge added a comment - In such cases people may suffix the target install directory with the version number or something similar. Or you may change the registry keys, or something like that.
Hide
Permalink
Timothy Fridey added a comment - - edited

Hi Julien,
At first I thought of course adding the version number to the install dir what a simeple solution. However I quickly realised that this has more side affects.

For example, in Windows 7/Vista you need to install datafiles that are to be edited in the AppData directory (otherwise you need to run your program with special privleges to be able to edit files under the 'Program Files' directory ).
If you change the suffix you can install two versions and you can now remove both including the add/remove programs entries. However when the user removes one of the versions this will remove the files installed to the AppData directory, and thus the remaining intalled program will not run without these files. I dont want to sufix this directory as I would like to continue using the other data from this directory, such as user profiles which are not removed by the uninstaller.

I still believe detecting a previous version and stopping the install is the best way around this whole issue.

Show
Timothy Fridey added a comment - - edited Hi Julien, At first I thought of course adding the version number to the install dir what a simeple solution. However I quickly realised that this has more side affects. For example, in Windows 7/Vista you need to install datafiles that are to be edited in the AppData directory (otherwise you need to run your program with special privleges to be able to edit files under the 'Program Files' directory ). If you change the suffix you can install two versions and you can now remove both including the add/remove programs entries. However when the user removes one of the versions this will remove the files installed to the AppData directory, and thus the remaining intalled program will not run without these files. I dont want to sufix this directory as I would like to continue using the other data from this directory, such as user profiles which are not removed by the uninstaller. I still believe detecting a previous version and stopping the install is the best way around this whole issue.
Hide
Permalink
Timothy Fridey added a comment - - edited

Ok, I have taken a look at the code behind CheckedHelloPanel and it looks as though it should be easy enough to create something I'm after.

Restrictions/Problems:
Currently Registry entries are matched on there uninstallName which is a combination of APP_NAME and APP_VER variables. Now as there is currently nothing in Izpack inforcing that APP_VER is a numerical value this makes determining the uninstallName for previous versions of software using a generic method impossible (e.g APP_VER name could be 'version 7 contains spaces whats the app name? whats the version?'). Not sure if the Izpack team plans on tighening up restrictions on things like this, it would make any future upgrade features built into Izpack much easier in my opinion.

Workaround:
I may be able to use a variable to accept a pattern matching string that can be used to identify the uninstallName. Along with checking some of the entries to be sure it is indead an Izpack entrie.

Again any feedback, suggetions, comments on this idea, are appreciated.

Show
Timothy Fridey added a comment - - edited Ok, I have taken a look at the code behind CheckedHelloPanel and it looks as though it should be easy enough to create something I'm after. Restrictions/Problems: Currently Registry entries are matched on there uninstallName which is a combination of APP_NAME and APP_VER variables. Now as there is currently nothing in Izpack inforcing that APP_VER is a numerical value this makes determining the uninstallName for previous versions of software using a generic method impossible (e.g APP_VER name could be 'version 7 contains spaces whats the app name? whats the version?'). Not sure if the Izpack team plans on tighening up restrictions on things like this, it would make any future upgrade features built into Izpack much easier in my opinion. Workaround: I may be able to use a variable to accept a pattern matching string that can be used to identify the uninstallName. Along with checking some of the entries to be sure it is indead an Izpack entrie. Again any feedback, suggetions, comments on this idea, are appreciated.
Hide
Permalink
Daniel Abson added a comment -

This would be an incredibly useful complement to the ConfigurationInstallationListener in 5.0, for enabling upgrade-type installs.

The reporter's suggestion of using APP_NAME + patternMatching(APP_VER) to detect previous installs on Windows, plus checking the installation directory for .installationInformation, uninstaller, etc (which would work for other platforms too), seems like the only way to do it without major changes. You'd also want to allow configurable prefixes for APP_VER (defaults e.g. 'v', 'ver', 'version') and a configurable hierarchy of post-fixes (default e.g. 'alpha' < 'beta' < 'rc' < 'none').

Is anybody working on anything like this right now?

Show
Daniel Abson added a comment - This would be an incredibly useful complement to the ConfigurationInstallationListener in 5.0, for enabling upgrade-type installs. The reporter's suggestion of using APP_NAME + patternMatching(APP_VER) to detect previous installs on Windows, plus checking the installation directory for .installationInformation, uninstaller, etc (which would work for other platforms too), seems like the only way to do it without major changes. You'd also want to allow configurable prefixes for APP_VER (defaults e.g. 'v', 'ver', 'version') and a configurable hierarchy of post-fixes (default e.g. ' alpha ' < ' beta ' < ' rc ' < ' none '). Is anybody working on anything like this right now?

People

  • Assignee:
    Unassigned
    Reporter:
    Timothy Fridey
Vote (1)
Watch (1)

Dates

  • Created:
    Updated: