7 replies to this topic

[aiernt]

I've been having problems with orphaned files in my builds using Installshield 2011. After doing much research I've found the following problem:

Here is some of my setup....
-I always do a major upgrade.
-I always update the product code and change the version.
-I know this is a no-no, but I have several folders that are dynamically linked (It's available so I use it. I don't have time or the resources to setup the folder structure and statically link 1000's of files that don't change. This is the reason dynamic linking is there and i'm using it.)

After several version upgrades I've found that some files (static and dynamically linked) leave orphaned entries in the following registry key. I do have some files set to permanent, and expect those to be incremented in the list, but not ones that are being orphaned.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls

The files listed in here have the counter incremented, and the system thinks these files are still in use by an installation, when in fact, no installation is on the system. Because of this it leaves these files orphaned on the system.

Here are my questions:
Why does this happen?
How do I prevent it?
What is the best way to clean up these registry values automatically?

thanks,
Rob

[Stefan Krueger]

This could happen if the file existed before your first install (maybe from another application).

[aiernt]

Thanks for the reply Stefan.

That's what is weird about this situation. This is a new project that I've recently created, and it's a new folder structure and deployment location. It's very weird to me that this is going on.

[vgimple]

Hi!

As it happens I have a similar issue - seems like this is "orphaned file week"

The scenario looks like this:
* We used to publish a version 1.0.0 of our product containing several components with shared DLLs and the likes. Unlike in the previous post we are not using dynamic linking anywhere.
* Now we produced version 2.0.0 and intended it to be a Major upgrade. Therefore I changed the ProductName, ProductVersion, ProductCode and UpgradeCode property. has also been changed. The Upgrade table has been authored to detect the previous Upgrade Code and perform a Major Upgrade of the previous product by completely uninstalling the old setup before installing the new one. Feature Stats are not being migrated.

Both product versions contain files that have identical names, but the component names and component GUIDs differ between 1.0.0 and 2.0.0 (the files are all being drawn from MSMs and the GUIDs of the MSMs which is appended to the component's "friendly" name has changed between 1.0.0 and 2.0.0). Sharing has been activated where it seemed appropriate (DLLs, ActiveX controls) in 1.0.0 as well as 2.0.0.

What I see is that if I run the 2.0.0 setup on a machine where 1.0.0 was previously installed, it removes 1.0.0 (messages like "Removing Files" and "Removing Shortcuts" show up above the progress bar) and installs the 2.0.0 version just fine, but *after* the setup most files that had already been part of the 1.0.0 version the share count after installing 2.0.0 is 2, not 1 (consequently the corresponding files are orphaned after uninstalling 2.0.0).

If I uninstall 1.0.0 via the control panel prior to the installation of 2.0.0 (as opposed to running the Major Upgrade that has been defined in the 2.0.0 installer) all the files of 1.0.0 are properly removed and a subsequent install + uninstall of 2.0.0 leaves no orphaned files.

All these tests are being performed on "clean" machines (VMs) where nothing but the bare Windows 7 x64 OS has been installed and nothing is being done on the files/folders inbetween the install/uninstall tests.

There seems to be a fundamental difference between manually uninstalling the previous version + running the new installer versus letting the new installer do its major upgrade, but I do not understand at all what I am doing wrong here, and I'd be grateful for any hints...

Volker


BTW: I think you are doing a terrific job here, Stefan - Flexera and Microsoft should definitely pay you a salary! I find some aspects of MSI setups highly confusing and without the posts in this forum I would often have been lost!

[aiernt]

I also see the same thing.

On a clean machine I install V1.0. If I remove V1.0 using add/remove before installing V2.0 then the SharedDLLs registry area is cleaned up like I would expect it.

If I Leave V1.0 and Install V2.0 which is set to do a Major Upgrade, I see the messages about removing files, shortcuts, etc and V2.0 installs, but in the Registry the Reference counts are incremented to 2, instead of being at 1.

What is the best way to clean up these registry entries?

[Stefan Krueger]

One way to avoid this problem is to set the Shared flag of the component to No and always use the same ComponentId for the file. The flag is intended for backward compatibility with non-msi installers. Windows Installer itself doesn't use it. Instead it keeps track of shared resources based on the ComponentId GUID.

I don't know from the top of my head which action evaluates the Shared DLL registry entry but my guess is that it's before the old version is uninstzalled:
Windows Installer looks at the entry, sees that its value is 1. So it knows it needs to write 2 in that entry because the file will be installed. (You might be able to find this in the log)
Now the old version gets removed, also decremetning or removing the Shared DLL count. (Put a custom action with MessageBox after RemoveExistingProducts to inspect the registry at this point).
Finally the new version is installed and the value of 2 is written to the Shared DLL registry entry.

This is my theory why this happens. Unfortunately it's not a solution to avoid the problem. Moving the Remove action near the end, after installation of the new version, might avoid the problem.

@Volker: thanks

[vgimple]

[Stefan Krueger]