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
- :
- SOLUTION to minor upgrade COM issue (orphaned COM registration)
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
‎Oct 24, 2014
11:19 AM
Minor Upgrade COM issue
For years our application has been distributed as a major upgrade.
Management wants to try minor upgrades in anticipation of offering upgrades between major upgrades.
The problem I am having is that a minor upgrade does not seem to remove COM information for the past install. This seems to have the effect of confusing the application and the application errors on startup.
In the registry under HKLM\Software\Classes\CLSID\{guid}\InprocServer32\ there are two different versions represented.
Let's say that I release the application with file version 1.0.0.500. That is listed in the registry.
I then create a minor upgrade to 1.0.0.600. This too is listed in the registry.
How do I get the minor upgrade to remove the 1.0.0.500 reference on upgrade? Is this possible with a minor upgrade. What also confuses me is why the app does not simply pick the right one based on its manifest file? I would assume that the manifest contains the appropriate version.
Thank you.
EDIT: A major upgrade will remove the registry entries correctly. I believe that a minor upgrade will only remove registry entries when they have been added to the remove registry key on a minor upgrade. Of course trying to maintain the remove registry key for minor upgrades would be a futile exercise as every build would have changes.
Management wants to try minor upgrades in anticipation of offering upgrades between major upgrades.
The problem I am having is that a minor upgrade does not seem to remove COM information for the past install. This seems to have the effect of confusing the application and the application errors on startup.
In the registry under HKLM\Software\Classes\CLSID\{guid}\InprocServer32\ there are two different versions represented.
Let's say that I release the application with file version 1.0.0.500. That is listed in the registry.
I then create a minor upgrade to 1.0.0.600. This too is listed in the registry.
How do I get the minor upgrade to remove the 1.0.0.500 reference on upgrade? Is this possible with a minor upgrade. What also confuses me is why the app does not simply pick the right one based on its manifest file? I would assume that the manifest contains the appropriate version.
Thank you.
EDIT: A major upgrade will remove the registry entries correctly. I believe that a minor upgrade will only remove registry entries when they have been added to the remove registry key on a minor upgrade. Of course trying to maintain the remove registry key for minor upgrades would be a futile exercise as every build would have changes.
(2) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 27, 2015
11:59 AM
Hi DLee65, hope you see this post
We had the exact same issue, and even opened a ticket with both Microsoft and Flexera to resolve this issue.
Neither Microsoft nor Flexera had a real solution to the issue, namely that MSI minor upgrades do not remove prior COM registration information, resulting in multiple orphaned COM registration entries that crash the application. In house, we call these 'duplicate COM entries'.
As you noted, adding and maintaining all the orphaned registration entries in the remove registry table is not manually feasible, however, it can be automated, not at build time, but at runtime...
The solution I developed involves a Custom Action DLL, built in C# using the Deployment Tools Fondation (DTF). You can get DTF with the WiX SDK, read about it here : http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
The CA only works if the new COM registration info has been added to the Registry table (ie: use 'COM Extract at build', not 'COM SelfReg').
Here's how it works :
The tests so far have been conclusive : we don't have any orphaned/duplicate COM registration entries after minor updates. This solution hasn't yet been used in production, but it should be soon. I have limited the scope of the CA DLL to scan only for components installed to our installation folder, so problems could still exist for components deployed to other folders, like Windows\System.
This problem exists since the very beginning of Windows Installer (15 years!), and I have seen many old posts asking about this; so far no one had a better solution than going the major update route.
Honestly, if management had not been so pent up on having minor updates, I would simply have kept the major update solution, like everyone else, but I think my solution is a good one. Maybe I'll put the code up somewhere.
We had the exact same issue, and even opened a ticket with both Microsoft and Flexera to resolve this issue.
Neither Microsoft nor Flexera had a real solution to the issue, namely that MSI minor upgrades do not remove prior COM registration information, resulting in multiple orphaned COM registration entries that crash the application. In house, we call these 'duplicate COM entries'.
As you noted, adding and maintaining all the orphaned registration entries in the remove registry table is not manually feasible, however, it can be automated, not at build time, but at runtime...
The solution I developed involves a Custom Action DLL, built in C# using the Deployment Tools Fondation (DTF). You can get DTF with the WiX SDK, read about it here : http://blog.deploymentengineering.com/2008/05/deployment-tools-foundation-dtf-custom.html
The CA only works if the new COM registration info has been added to the Registry table (ie: use 'COM Extract at build', not 'COM SelfReg').
Here's how it works :
- For each component marked for installation, retrieve all matching records from the Registry table
- For each resulting component/Registry record set, determine if any existing registry entries on the PC would become orphaned.
- Add the orphaned registry entries from the previous step to the Remove Registry table.
- Let Windows Installer proceed to remove said registry entries...
The tests so far have been conclusive : we don't have any orphaned/duplicate COM registration entries after minor updates. This solution hasn't yet been used in production, but it should be soon. I have limited the scope of the CA DLL to scan only for components installed to our installation folder, so problems could still exist for components deployed to other folders, like Windows\System.
This problem exists since the very beginning of Windows Installer (15 years!), and I have seen many old posts asking about this; so far no one had a better solution than going the major update route.
Honestly, if management had not been so pent up on having minor updates, I would simply have kept the major update solution, like everyone else, but I think my solution is a good one. Maybe I'll put the code up somewhere.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jan 29, 2015
01:07 PM
Thank you for the suggestion. It does seem like a workable solution.
I am familiar with the logic because at one point my build process was leaving some registry keys behind because I was attempting to clean a build with an updated version number and so it would never really clean up the registry. So I had to follow the same logic to create a PowerShell script to clean out the registry.
I have not worked with DTF yet, but the process sounds straight forward enough.
Dan
I am familiar with the logic because at one point my build process was leaving some registry keys behind because I was attempting to clean a build with an updated version number and so it would never really clean up the registry. So I had to follow the same logic to create a PowerShell script to clean out the registry.
I have not worked with DTF yet, but the process sounds straight forward enough.
Dan
