Updating versions leaves folder behind

[Sheri_Steeves]

Hello,

I'm having some problems with leftover folders when I upgrade my application through my installer.
Here is my sequence:

1. Install version 1.0 into a custom location ( user changes the $TARGETFOLDER$ through the Destination directory dialog).
2. Install version 1.1
- detects prior version and prompts user to confirm upgrade
- if user says yes, runs Install/Remove MSI package [remove=all]
3. If remove is successful, continue with install; this time leave $TARGETDIR$ in the Destination dialog alone.
4. I end up with the custom folder from step 1 and the regular $TARGETDIR$ created in step 3.

I tried removing the directory manually using the Call DLL Function plugin but this throws an error "cannot load plugin".

Code: Select all

        Call DLL Function $WINSYSDIR$\kernel32.dll->RemoveDirectoryA


I also noticed that the SWIDTag is also left in the folder.

Is there a way to delete this folder?

Thanks,

Sheri

[FrancescoT]

Dear Sheri,

honestly, I just tried your steps and the target folder created at point #1 it is completely removed during uninstall.

I don't know if additional files or folders are added to that targetdir after initial install (... for example; added during your application execution).
If This is the case, by default MSI engine will only remove the files installed by the setup package and any files subsequently added will be kept.

Hope this helps you.

Regards.

[Sheri_Steeves]

Francesco,

The problem is not on the uninstall. If I just install my application into a custom destination folder and then unintall either by running the same version of the install program, using the Uninstall link in the start menu or the control panel then everything is correctly removed.

We version our installs using the revision code so that installing 1.2 over version 1.1 prompts the user that a previous version is installed and that it will be removed before installing the new version. You can think of this as an in-place upgrade basically. It is in this scenario, when a custom destination folder was used when installing version 1.1, that upgrading to version 1.2 will leave the custom folder on the system.

The difference is also that the "upgrade" calls Install/Remove MSI package [remove=all] while the direct uninstall calls Apply Uninstall.

I did notice in the MSICode that Create Folder is only called for the subfolders that I added to the Files collection and is never actually called for the $TARGETDIR$ directly. I added all my file and folders through the Files page in the Design view.


Thanks,

Sheri

[FrancescoT]

Dear Sheri,

I done exactly the same as you with my verification. I haven't removed the package via control panel, but only rebuilded the project again in order to be recognized as a new version (due REVISIONCODE update) by the installer process.

However, it is strange that you found differences with "Install/Remove MSI package [remove=all]" and Apply Uninstall functionality.

During my test I have created a new project from scratch, added a file to it and then, installed (not using the dafault target dir), rebuilded once again and reinstalled over the previous installation using the default target dir.
Doing this, the target folder created by the first installation has been completely removed during uninstall (via "Install/Remove MSI package [remove=all]").

Regards.

[Sheri_Steeves]

Francesco,

I've attached a small sample project here that duplicates my issue.

My builds are configured with a single setup option and to remove only ( no maintenance).

The way I have my builds set up is that I create a new project file (.mpr) for each version (revision) by doing File-Save Project As and manually changing the revision code. The revision code is not updated for each build but only manually when I create the project file for the new version.

The project file contains the product version as a compiler variable and is referenced in the output file name and in the Product Version field on the Project Summary page in Design view. I also use this variable to set the product version through the command line.

There are two project files -> Test_1.0.mpr and Test_1.1.mpr which create TestSetup_1.0.exe and TestSetup_1.1.exe respectively.
They both copy two dummy text files -> one in the root of the $TARGETDIR$ and one in $TARGETDIR$\Help.

Once the two setups are built, here are the steps I am using:

1. Install TestSetup_1.0.exe into a custom named folder ( C:\Program Files (x86)\Test1 Custom Folder).
2. Then run TestSetup_1.1.exe -> it will prompt to remove the previous version installation.
3. After the previous version is removed, let the install continue but do not change the name of the install folder.

You should have two folders : C:\Program Files (x86)\Test1 Custom Folder and C:\Program Files (x86)\Test1

Is there something in how I have structure my builds that is causing this?

Thanks!
Sheri

[FrancescoT]

Dear Sheri,

I will verify it and I'll be back as soon as possible.

Regards.

[FrancescoT]

Dear Sheri,

Please use the attached file which contains your modified project.

You found this behaviour because you have included with your project the "ISO/IEC 19770-2:2009 software identification (SWID) tag for your application".
(this properties are defined with "Summary, UAC, and ISO" page in InstallAware design view).

During package installation, the runtime procees stores a "xxxx.swidtag" file under the target folder.
This file is not removed during uninstall and consequently, the target folder can't be deleted by MSI engine (because not empty).

I have modified your original projects, forcing "xxxx.swidtag" file deletion with a call to "Delete Files $TARGETDIR$\*.swidtag (when uninstalling)" command.
I have also changed your original REVISIONCODE setting for both Projects (available with Project Options SHIFT+CTRL+F11), in order to have it changed automatically upon rebuild (recommended).

Regards

[Sheri_Steeves]

Francesco,

Thanks so much for the explanation; now it makes total sense. I should have realized what was happening - I saw that file in the folder too.
I guess I was expecting the uninstall to also remove the swidtag.

Sheri

[FrancescoT]

[stingraysc]

I've also just run into this -- the .swidtag file is removed during uninstall, but it must happen after the MSI is executed, because the $TARGETDIR$ is left behind. This is a bug, correct? Do you expect this to be fixed or should the workaround of forcing the file to be deleted using an MSI command be considered a permanent solution?

*UPDATE* -- Actually, even with the call to delete the .swidtag file during uninstall (this call is made before Apply Install), the parent of my $TARGETDIR$ is left behind. For instance, if my $TARGETDIR$ is "C:\Program Files\Dir1\Dir2", then "C:\Program Files\Dir1" is left behind. This doesn't happen if I remove the ISO/IEC 19770-2:2009 SWID properties in the designer.

[FrancescoT]

Dear Stingraysc,

you should handle such file using the same approach illustrated with the above project ( sheri.rar ), otherwise the targetdir will be not removed.

Honestly, this is not currently marked as a bug.

Regards

[stingraysc]

Thank you Francesco, but as I stated, this isn't working for me -- the parent directory of $TARGETDIR$ is still left behind and I can't figure out why.

[FrancescoT]

Dear Stingraysc,

if you post a very basic project that replicates the issue, I'll try to have a look.

Regards