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
- :
- Re: Shared count not working as expected
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
‎Sep 29, 2009
04:59 PM
Shared count not working as expected
Hello,
We have a shared merge module that is included in quite a few of our apps. this merge module is our own product and therefore we control the created/modification of this merge module.
We just recently updated it to our next version of the product, therefore some files were removed from the merge module, and these were key files.
The components themselves did not change, just re-set the key files to the new files.
All seemed okay in our testing and everything seems to be working correctly, but then I did some major upgrade testing from a version of our software that contained an earlier version of this merge module.
The upgrade seemed to worked correctly as it correctly uninstalled all files, including the shared merge module files, as it was not used by any other products, and continued to install the product and the newer merge module files. After the install verified that all the files were correctly installed/upgraded and they were.
But in testing the uninstall I noticed that most of the shared merge module files were not removed. So I redid the test and noticed that even though the previous version was correctly removed and the shared counts were correctly decremented and removed that when the new version finished installed that it somehow set the shared count on all the merge module shared files to 2. The log even shows that they get incremented to 3 and then on finish they are 2.
I have no clue as to why the shared count is getting incremented to 2, it seems that it records the current shared count and the increments that by 2 and then it decrements the count at the end by one leaving it set to 2.
At this point the shared merge module files will never be uninstalled.
Has anyone run into a situation such as this and is there anything that I do to fix this issue?
I at first figured that maybe since the components all have the same GUID as the previous version, but with different key files that it was causing an issue. So I changed all the component GUIDS, but this did not seem to do anything.
Does anyone have any clues as to what I can try to see if I can get this fixed?
Thanks,
We have a shared merge module that is included in quite a few of our apps. this merge module is our own product and therefore we control the created/modification of this merge module.
We just recently updated it to our next version of the product, therefore some files were removed from the merge module, and these were key files.
The components themselves did not change, just re-set the key files to the new files.
All seemed okay in our testing and everything seems to be working correctly, but then I did some major upgrade testing from a version of our software that contained an earlier version of this merge module.
The upgrade seemed to worked correctly as it correctly uninstalled all files, including the shared merge module files, as it was not used by any other products, and continued to install the product and the newer merge module files. After the install verified that all the files were correctly installed/upgraded and they were.
But in testing the uninstall I noticed that most of the shared merge module files were not removed. So I redid the test and noticed that even though the previous version was correctly removed and the shared counts were correctly decremented and removed that when the new version finished installed that it somehow set the shared count on all the merge module shared files to 2. The log even shows that they get incremented to 3 and then on finish they are 2.
I have no clue as to why the shared count is getting incremented to 2, it seems that it records the current shared count and the increments that by 2 and then it decrements the count at the end by one leaving it set to 2.
At this point the shared merge module files will never be uninstalled.
Has anyone run into a situation such as this and is there anything that I do to fix this issue?
I at first figured that maybe since the components all have the same GUID as the previous version, but with different key files that it was causing an issue. So I changed all the component GUIDS, but this did not seem to do anything.
Does anyone have any clues as to what I can try to see if I can get this fixed?
Thanks,
(4) Replies
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 15, 2009
03:26 PM
Bump.
I might be having similar issues, and am curious if anyone else knows. :confused:
I might be having similar issues, and am curious if anyone else knows. :confused:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 16, 2009
09:26 AM
What we have discovered so far is that if you have a shared component that contains multiple files and one key file and you then remove the key file and place one of the other sub-files of the same component as the key file then this will cause the shared count to be corrupt.
We updated our merge module so that a new file would be the key file instead of one of the other files within the component. Since all the files were non-versioned files we just added a versioned dll file, which only contains version information, and this seems to have fixed the issue.
The only problem we have is that one of our products was released with the bad shared count merge module, therefore with that one out it will cause shared counts of those files to be out of sync and therefore not be removed on uninstall. Do not know of an easy way to fix that though....
sneale, don't know if this will help you as I do not know if you have your components set up the same way.
We updated our merge module so that a new file would be the key file instead of one of the other files within the component. Since all the files were non-versioned files we just added a versioned dll file, which only contains version information, and this seems to have fixed the issue.
The only problem we have is that one of our products was released with the bad shared count merge module, therefore with that one out it will cause shared counts of those files to be out of sync and therefore not be removed on uninstall. Do not know of an easy way to fix that though....
sneale, don't know if this will help you as I do not know if you have your components set up the same way.
Not applicable
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 16, 2009
10:18 AM
I have some pesky files that like to stay behind on uninstall as well as a shortcut.
The files stay behind only when I upgrade from an old version, and then uninstall the upgrade version.
I find it really interesting that removing a key file, and then putting in a new key file causes your sharecount to be corrupt. I don't use another subfile of the same component, but I do find a new version/path of our key file and use that. Is that supposed to be normal behavior?
That's what I do with all our installations to upgrade our files. If that indeed is the trigger of the problem, maybe that's why I'm having issues.
I posted over here a little more about share count issues and my experience with tech support if you're interested.
http://community.installshield.com/showthread.php?t=190426
Of course, I'm not using a custom merge module or replacing key files with subfiles of the same component. So our situations may not be that similar. But I've been scouring for threads talking about ShareCount issues cause I suspect it has something to do with that.
Please reply if you have any more speculation. Thanks!
The files stay behind only when I upgrade from an old version, and then uninstall the upgrade version.
I find it really interesting that removing a key file, and then putting in a new key file causes your sharecount to be corrupt. I don't use another subfile of the same component, but I do find a new version/path of our key file and use that. Is that supposed to be normal behavior?
That's what I do with all our installations to upgrade our files. If that indeed is the trigger of the problem, maybe that's why I'm having issues.
I posted over here a little more about share count issues and my experience with tech support if you're interested.
http://community.installshield.com/showthread.php?t=190426
Of course, I'm not using a custom merge module or replacing key files with subfiles of the same component. So our situations may not be that similar. But I've been scouring for threads talking about ShareCount issues cause I suspect it has something to do with that.
Please reply if you have any more speculation. Thanks!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 19, 2010
09:52 AM
I do not know, but shared count issues are always coming up.
We have a new one where we have a suite install that installs many products within on msi install. If any of the standalone products already exist on the machine then the suite install will detect and uninstall these through the Major Upgrade table.
This seems to work fine, but we did notice that some shared components remain behind on the system after the suite product has been uninstalled.
I performed the testing to verify what is happening and here is what it looked like to me.
I first installed 2 standalone products on the machine and checke the shared counts of the shared files. They looked correct.
I have started the suite installer and watched what happened to the system and shared registry keys while the suite detected and uninstalled the 2 products. The first one uninstalled fine and the shared counts were correctly decremented. Then the suite install does move validating and starts the uninstall of the 2nd product. Again it looked okay as all files/registry keys and shared files were correctly removed. Nothing left behind.
The suite then continued the install and installed all the files and registry entries and shared entries. When done I checked and sure enough some, but not all, of the shared components had shared counts of 2 instead of 1 as they should be. Since these components are not in my install twice I could only assume that what is happening is that it is not use to uninstalling more than 1 product during major upgrade, therefore what it is doing is just before uninstalling the 2nd product it records what is shared is and sets it so that it will increment the shared count to 2 when it gets installed. It then contiunes the uninstall of the 2nd product and since the shared counts are only 1 they are correctly removed and gets uninstalled. Since the suite install internally set the shared count on these components to 2 that is how it was installed and therefore incremented the shared count too much.
Anyways that is what I think is happening, but if anyone has any other ideas as to what is happening then let me know how fixable it is.
Coming up with a custom action to correct for this will be a bit of work, so if there are any quick solutions to this I wouldn't mind finding out about them.
Thanks,
We have a new one where we have a suite install that installs many products within on msi install. If any of the standalone products already exist on the machine then the suite install will detect and uninstall these through the Major Upgrade table.
This seems to work fine, but we did notice that some shared components remain behind on the system after the suite product has been uninstalled.
I performed the testing to verify what is happening and here is what it looked like to me.
I first installed 2 standalone products on the machine and checke the shared counts of the shared files. They looked correct.
I have started the suite installer and watched what happened to the system and shared registry keys while the suite detected and uninstalled the 2 products. The first one uninstalled fine and the shared counts were correctly decremented. Then the suite install does move validating and starts the uninstall of the 2nd product. Again it looked okay as all files/registry keys and shared files were correctly removed. Nothing left behind.
The suite then continued the install and installed all the files and registry entries and shared entries. When done I checked and sure enough some, but not all, of the shared components had shared counts of 2 instead of 1 as they should be. Since these components are not in my install twice I could only assume that what is happening is that it is not use to uninstalling more than 1 product during major upgrade, therefore what it is doing is just before uninstalling the 2nd product it records what is shared is and sets it so that it will increment the shared count to 2 when it gets installed. It then contiunes the uninstall of the 2nd product and since the shared counts are only 1 they are correctly removed and gets uninstalled. Since the suite install internally set the shared count on these components to 2 that is how it was installed and therefore incremented the shared count too much.
Anyways that is what I think is happening, but if anyone has any other ideas as to what is happening then let me know how fixable it is.
Coming up with a custom action to correct for this will be a bit of work, so if there are any quick solutions to this I wouldn't mind finding out about them.
Thanks,