#594 Windows Installer didn't find previous custom install folder

Installer (3)

Windows 7 x64

Just downloaded the new 0.8b3 (not listed in the Group area yet) and went to update my copy. I happened to install it to a custom folder instead of the default on that the installer selects depending on x86 or x64 system.
Installer selected this folder: C:\Program Files (x86)\KompoZer
However, I happen to have more than one drive on my system and I tend to keep programs off of the Windows installed drive since I keep it at a limited size. So, it didn't find the folder I did install the program to, which was E:\Program Files (x86)\KompoZer

If you can get the installer on future builds to recognize the place the person previously installed the program to, I would appreciate it. I mean, this is a minor thing, but would be nice so I don't have to manually change the drive on the install page. :)


  • PanuWorld

    It looks like the AppId value specified for Inno Setup has been changed from "KompoZer" to KompoZer's GUID (probably optional AppId was not specified previously, and now it has been set to the KompoZer's GUID). This causes the setup program not detect the package as an update to the previous installation of KompoZer.

    Result: If the 0.8 is installed in the save folder as 0.7.x, setup considers it as a separate installation: this leaves the old version to the Add/Remove Programs list beside of the new version. If the user then uninstalls the old version to remove the unnecessary Uninstall entry and uninstaller files, the new installation is destroyed, too.

    Changing Inno Setup AppId during software lifetime is generally not a good idea, especially because Inno Setup AppId does not need to be same as the GUID of the application. Only requirement for Inno Setup AppId is that it should be same in all versions of the product.

    However, KompoZer is in 0.x phase, so if AppId needed to be changed, it was better to do it now than after 1.0. — But when upgrading from 0.7.x to 0.8, remember to first uninstall the 0.7.x before installing 0.8 (unless you install 0.8 in different folder than 0.7.x)! — Later versions will update existing installations correctly (if AppId is kept the same from now on).

  • rickmastfan67

    Well, this happened when I was upgrading from 0.8b2 to 0.8b3.

  • Nobody in the small Kompozer team uses Windows, and we’re aware that our first Windows installers might have a few issues. We’ll have a look at that for the next release, but I have no idea at the moment whether this is possible or not with the installer system we use (= Inno Setup 5).

    Thank you for your bug report.

    -- kazé, Kompozer lead dev.

  • Panuworld > I hadn't seen your comment, sorry.

    You’re perfectly right: with the 0.8b3 release we’ve changed the AppId to match KompoZer’s GUID. Can you tell me wether that’s correct or not?

    For 0.8b2 our l10n lead had chosen a specific GUID for every installer (one for each of the 18 supported languages...) but after some thought I've been afraid it could be a source of conflicts — e.g. when someone installs an English version of KompoZer before finding out there's a localized version. So I decided that all KompoZer installers had to have the same AppId, and I chose KompoZer’s own GUID for that.

    If using KompoZer's GUID as the installer's AppID is correct (I'll trust you on this), this problem shouldn't happen again with the next upgrades. If you tell me we should use a distinct AppId, well... the problem will occur once more.

    -- kazé

  • PanuWorld

    GUID as IS AppId is good choice because GUID is not expected to be changed anymore(?) By default IS uses AppName as AppId, which can definitely change for some reason. Therefore explicitly specifying an AppId is recommended. Now you have defined it, so setup will automatically update existing installations for now on. IS does a very good job with that. (Note: IS does not uninstall the previous version. It overwrites the old files with the new ones, leaving old-version-only files intact. When the uninstaller is finally executed, it uninstalls "stacked" installations in reverse order, practically removing all files ever installed for any version. If some old-version files must be really deleted during update installation, there is [InstallDelete] for that.)

    Same AppID for localized versions is a good idea because of the reason you pointed out. (You can still install several versions or languages at the same time by manually changing the installation directory. IS appends a counter to AppId automatically to allow several uninstallers with same AppId coexist in the Uninstall registry key.)

    Whenever changing the AppId for any reason [or introducing it (with different value than previous AppName) if it was unspecified], the user should be instructed to uninstall the previous version before updating, just to avoid creation of several uninstallers. If you did not do that, there will be several uninstall entries in Add/Remove Programs although they will uninstall mostly the same files. Running any of them will delete the files belonging to that version, usually breaking the other versions in same directory. To fix this, just run all of those redundant uninstallers to remove them from the Add/Remove Programs (and remove the uninstaller files associated with each) and then reinstall the version you like to use.

    I have used IS for one commercial software deployment for 6+ years, so I am pleased if my comments can help the KompoZer team.

  • Thanks a lot for sharing your experience on InnoSetup with us, that's *very* helpful.

    For KompoZer 0.7 we've re-used Nvu's GUID, which has raised a few issues regarding addon compatibility because we use a lower version number than Nvu does. That’s why we've generated a new GUID for KompoZer 0.8b, and it's not expected to change any more for the next branches.

    So this bug should be fixed. To be confirmed with the next release. :-)

    -- Kazé

    • status: open --> closed-fixed
    • labels: 1246439 --> 1373895
    • labels: 1373895 --> Installer