I had considered trying the "Reg free" approach, but it got complicated quickly. With several hundreds EXE/DLL/OCX, trying to get our main (entry point) application Reg free did not work, and automating the entire process seemed complicated too, so I did not pursue that solution. Admittedly, I was the only one trying to Reg free our app, and I had no previous Reg free knowledge, it's quite possible I goofed up. It's something I'd like to reconsider sometime in the future though. TBH, I'd rather we migrate our application to C# and not have to deal with COM anymore, but re-coding and re-engineering our entire application to C# is unfortunately not possible... What are the downsides to going Reg free? Any performance hit? What happens if some ActiveXs get registered, does it break the Reg free? ... View more

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 : 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. ... View more

I did, but that's the entire list of registry entries that can be written, which can be different than the actual list of registry entries that will be written, especially in a minor upgrade. It's what I'm using now, but I would prefer to not have to process the entire table, only the entries scheduled to be actually written/installed. Anyone has an idea how to get, at runtime, the actual list/view/table of registry entries the Windows installer engine is going to write during the WriteRegistryValues action? ... View more

Also note: When rebuilding the msi package with updated ActiveX files using the same msi component codes, same basic msi project def., if we specify the previous msi package as a reference for a MinorUpgrade item, the IS2014 IDE *does* warn about registry entries that will be orphaned, as shown below : ISDEV : warning Val0009: A registry entry has been removed from the component 'AlphaBravoCharlie.dll.v1.0'. This key must be added to the RemoveRegistry table, otherwise it will be orphaned by an upgrade. '0|interface\{64973099-33b4-4701-b72f-64ce94df2604}\typelib|'. c:\abctest\sources.v1.1\kit.previous\abcinstallermsi.msi Since the build engine is aware of the specific registry keys that will be orphaned, having a provision to automatically add these keys in the RemoveRegistry table would have been the definitive solution to the problem... Could InstallShield not implement this? ... View more

Seriously though, how do people typically go about updating their ActiveX components? Are they always doing major updates? ActiveX COM may not the favored tech today, but it's still going to be around for some while, and the Windows Installer service has also been around for a while now: how is it that Microsoft or InstallShield hasn't made it easier to do something as simple as updating an ActiveX DLL? It baffles the mind. :confused: ... View more

Thanks for the clarifications Michael. I finally got a proof of concept set of msi packages to do a minor upgrade from v1.0.0 to v1.1.0 successfully, with no leftover residual registration info from the old ActiveX component, by using this method when building the msi package v1.1.0: [LIST=1] On the msi component for the old ActiveX, set the Condition to '0' (false) to force a removal (I also set Reevaluate Condition to Yes - not sure if necessary) Add the updated ActiveX as a new msi component, thus creating a new component code for the updated ActiveX DLL/OCX/EXE (GUID) *Note: the updated ActiveX replaces the old one, in the same path when installed. Keep the Product Code and Upgrade Code unchanged from msi package "v1.0.0" to "v1.1.0"; new Package Code always generated on build as per default IS settings Granted, this method works, but it makes it impossible to use a "static" basic msi project for automated builds and requires manually editing the package definition for every build. I'm guessing using "extract COM at build" is not possible either. It also means keeping ALL previous versions of all ActiveX DLL/OCX/EXE in the latest msi package, since the last major upgrade. Even though my proof of concept msi package had only one ActiveX DLL to update, arranging the msi for a successful minor update proved tedious and very hands on; doing this for 20+ components every time we need to build a package will be a major setback vs. our current automated build process... Surely we are not the first to hit this problem. How do others deal with the ActiveX registration/minor upgrade issue? ... View more

So, to clarify: Say I have an ActiveX DLL, with one function, say Function DoThis(); once compiled I get a v1.0 typelib version. This DLL is delivered in a v1.0.0 MSI package, with the rest of the application. Adding a Function DoThat() to that ActiveX DLL will bump its typelib to v1.1, and changes its COM registration accordingly. This DLL is delivered in v1.1.0 MSI package, with the rest of the application. Let's say only this DLL has changed. Note that any exe or library compiled to use the typelib v1.0 remains compatible with the v1.1 typelib. By my understanding of your explanation and the component rules, since the typelib registration has changed, going from the MSI v1.0.0 to v1.1.0 could only be done by a major upgrade, right? If this is indeed the situation, it's means minor updates can never be used in any scenario where ActiveX components need to be updated, right? Is the industry norm for updating applications with many ActiveX COM components (exe/dll/ocx) to always do major updates? If not, what? Any feedback or insight into this issue greatly appreciated. ... View more

/bump Other than the current workaround, has a real fix to the issue been found? Shouldn't Microsoft be the one who should fix the "Windows Installer Coordinator" to not deadlock installations when they are launched from the same root process? ... View more

Actually, our COM components do unregister themselves when uninstalling - there is no trace of them left in the registry after the uninstall. As for the COM-extract best practice, this can only be done for the Key file; our files are added using a Dynamic Link (w. best practices), so this solution is not feasible for us. Also, the COM-extract process results in registry entries that are somewhat different than the component's self-registration process: the COM component is usable by programs but "invisible" for referencing in VB6 or searching through our registry utility. As for coding standards, our COM components are all "Binary Compatible", and we never break an interface. Adding new methods/properties to an existing interface does not break it, it just "versions up" and remains fully backward compatible with every program that used the previous versions. Said previous programs can use the new version without even being recompiled. If you *change* and existing method or property signature, then you are breaking the interface and are indeed creating a 'new' component', thus requiring a new GUID. You really should not just lightly assume we don't know how COM works, nor imply we're not using best practices. ... View more

Well, we had to use a Major Upgrade and that solved the double registration of COM components, but it's clearly not the ideal scenario. Does anyone know of a way to unregister COM components before they are upgraded in a Minor Upgrade scenario? TIA ... View more

Thanks Robert!! I don't have the time to try this out right now, but I'll keep a sticky on this and update when I try it: it looks like it should solve the problem nicely! (and thanks to chrislynn5 for bumping the thread! 😄 ) ... View more