Renamed file that is installed, upgrade scenario leaves old one behind

[EGMuser]

Hello.

I have the following scenario: (or rather, here is a simplified example of the scenario)

Product version 1.2.0.0 - We install the following files:

C:\Programs Files\SomeProduct\SomeFile.txt
C:\Programs Files\SomeProduct\SomeFolder\AnotherFile.txt

Now later on with a different version, we decide that we are going to rename SomeFile.txt to NewFile.txt and we also want to rename SomeFolder to NewFolder.

If I build a new installer, say, 1.2.0.1, and I try to run it with Upgrade option after 1.2.0.0 was installed, then the end result is that SomeFile and SomeFolder are left intact, and only the new files and folders are added, so after an upgrade, we end up with something like this:

C:\Programs Files\SomeProduct\NewFile.txt
C:\Programs Files\SomeProduct\SomeFile.txt
C:\Programs Files\SomeProduct\NewFolder\AnotherFile.txt
C:\Programs Files\SomeProduct\SomeFolder\AnotherFile.txt

When in reality, the upgrade should have ideally left us with this: (the same as a clean install)

C:\Programs Files\SomeProduct\NewFile.txt
C:\Programs Files\SomeProduct\NewFolder\AnotherFile.txt

So my question is, what do I need to do to both versions 1.2.0.0 and 1.2.0.1 so that, when this kind of renaming is done and an Upgrade is done, the old files are removed and only the new files are copied and left behind?

I noticed there is an option for Major Upgrade that has an option to "Uninstall old version first, then install new version" but I am not sure if this can be done within minor versions. How can I go about handling the above scenario? If this requires that the version change be a "Major upgrade" then how can I define that so that this scenario will work?

Thank you!

EDIT:

As a follow-up to my own testing, I tried changing the Upgrade Code of the new version to something else, and then I selected the Major Upgrade on the Upgrade Scenarios to use the Upgrade Code of the previous version in determining major upgrades, but the end-result is that I still don't see the previous file removed when I do an upgrade... 😞

[skolte]

Perhaps you need to add the file names to be removed to RemoveFile table. See this.

[EGMuser]

Hello.

Thank you for the reply. It looks like the RemoveFile table is meant to remove additional files that may have been made after the product was installed. In my case, however, and given the example I posted, the files I want to remove were actually installed as part of the product. They are correctly removed if I uninstall the product, but they are not correctly removed if I upgrade instead.

This does seem to be a "work-around" but I was hoping there would be an actual way to specify for all files from a previous version to be removed, instead of having to list each one of the files in the RemoveFile table. If the upgrade process did an uninstall of the previous version and then an install of the new version, then I would imagine it would have worked, but apparently this is not what is happening.

I did try using the RemoveFile table and it wasn't working properly, but the link you provided contains a PDF file with some samples. I will try again now that I have a better explanation of it and see if it works.

Thank you!

[EGMuser]

I tried this approach, and here are my findings:

If I add SomeFile.txt to the list of files that need to be removed on the later version, then when I upgrade, the file is still not removed. It is only after I uninstall the later version that both SomeFile.txt and NewFile.txt get removed.

So it looks like this option only works for files you wish to remove that were not part of the list of files that were installed. (As the sample document mentions.) It seems that the only way this option could work is if we added the file to the RemoveFile table of the older version first. (And even then, I am not sure if this will work as I did not test this scenario because it's just not an acceptable solution anyway.)

There is no way to know on that older version if that file will be renamed on a future version, therefore, the only way I could see this option working is if we added all the files that are installed into this RemoveFile table, which doesn't seem like the correct approach to me.

I should mention that the reason this renaming can arise is because we might want to do something like renaming MyApp.exe to MyCoolApp.exe in a future release, so in that case, an upgrade should remove MyApp.exe and leave only MyCoolApp.exe in the installation directory.

There has to be a way to handle this case, otherwise, the Upgrade option would be useless any time a file got renamed. So how can this be achieved without telling the customer to manually uninstall the old version first any time a file or directory gets renamed in the project?

[skolte]

Are you open to use InstallScript or a custom action to remove files? For this you need to know if
1. the user will have admin privileges to delete the file
2. the filename.

If yes, I can probably try to put together a sample that might show how to do it. let me know...

[EGMuser]

Hello.

I've gotten some VB scripts added to the project, so it looks like I can at least get that type of thing working. (I hadn't done any VB Scripts on the installer until very recently, so I just acquired that knowledge, thank goodness!) I think I can manage doing that, however, 2 things:

1 - How would I specify the install path on a VB Script action? If I did this through VB Script, I would need to know the full path of the files, correct? These would be files from the Program Files directory (i.e. installation dir)

2 - I take it I would also have to manually handle the removing of the keys added to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs correct? That sounds like it could get messy.

3 - Overall, I was hoping that I could somehow tell the installer the following: "If someone tries to run this installer with "Upgrade mode", first run an Uninstall of the previous version to completely uninstall that, and -then- run a fresh install of -this- new version."

If I could somehow get the installer to do this, then I think it would work perfectly, because then, -any- directory I rename, or file, etc. would always be handled for me, whereas using VB Script on upgrade mode, I would have to specify all the files on the VB Script action, I would have to potentially handle files that might have been renamed more than once, (e.g. from SomeFile in V1.0 to SomeNewFile in v1.1 to SomethingElse in v1.2), handle the SharedDLL etc. Ideally, this is the option I would like to implement and/or enforce. Is there any way to do this instead?

Thank you for the replies and the help!