This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Basic MSI removing shared files script install
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 19, 2012
03:16 PM
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.
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.
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 20, 2012
06:28 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Mar 21, 2012
10:20 AM
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
I was not selecting a key file so when I did that all is good now with the shared files.
Thank you
Brandon