cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Brandon_Lowe
Level 6

Basic MSI removing shared files script install

I'm working on our first Basic MSI install. We have been using Installscript installations for the last 14 years. In the previous installs I have a set of components that goes to commonfiles and the fileshave been marked as shared. This has worked great from install to install. The files stay until you uninstall the last copy of our program and then they get removed.

Now with the Basic MSI install I have set the same component as shared but it will uninstall those files everytime. They are marked as shared and have a ref count with 2 on them but still get removed.
What am I msiing here?
Why are they being removed before the ref-count hits 0?
Other than marking the files as perminate which I do not want to do how can I fix this?
I think it is a bug.


******EDIT*******
I ran some more tests and here is what I found.

If I install 2 of our other products that use the same DLL in common files they add to the ref count in the registry. So the count is now at 2.
I then install our new product using a Basic MSI install and it uses the same DLL and adds to the ref count so now it is at 3.
I then uninstall the new product and it reduces the ref count back down to 2 but it deletes/removes the DLL.
So I now have reg entries that say 2 for some DLL's but those DLL's have been deleted.
The Basic MSI install is using the ref count but still deletes the files even if the ref count is above 0.

This is a big problem for us.
Labels (1)
0 Kudos
(2) Replies
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

In general, the most likely cause of behavior such as this (or files being left behind after uninstall) would be not adhering to Windows Installer component authoring rules. For example, if any of these files, being shared across installations, are not the keyfile of a component, a shared reference count on the file has no meaning (with the exception of files installed to System32) as Windows Installer will not pay attention to the ref count during uninstall and will just remove the component containing the file (and therefore the file will be removed). Only keyfiles of components having a ref count will matter (again with the exception of files in components installing to System32).

The following article should be used as a general guideline for authoring components in MSI packages:
Defining Installer Components - http://msdn.microsoft.com/en-us/library/windows/desktop/aa368269(v=vs.85).aspx

The following articles also contain some valuable reference information regarding Windows Installer component rules:
Organizing Applications into Components - http://msdn.microsoft.com/en-us/library/windows/desktop/aa370561(v=vs.85).aspx
Changing the Component Code - http://msdn.microsoft.com/en-us/library/windows/desktop/aa367849(v=vs.85).aspx
What happens if the component rules are broken? - http://msdn.microsoft.com/en-us/library/windows/desktop/aa372795(v=vs.85).aspx

In general, Windows Installer tends to be rather unforgiving if these rules are not followed when compared to something like a pure InstallScript project (InstallScript doesn't really care in most cases and will allow quite a lot of authoring scenarios not possible with MSI).

Also, besides component rule issues, a verbose log of the uninstall may provide some additional information. Windows Installer verbose logs, combined with an MSI file, do tend to provide a fair amount of useful information on why some action occurred.
0 Kudos
Brandon_Lowe
Level 6

Thanks Josh,
I was not selecting a key file so when I did that all is good now with the shared files.

Thank you
Brandon
0 Kudos