Shared components causes constant problems - is there a better way than .MSI project?
My naive opinion is for my software - having components marked as shared is only asking for trouble.
But I have a feeling that if I don't have them as Shared, then nothing happens when you uninstall - no unregistering, no file removal. Then I'm stuck resorting to file removes and custom actions.
Nothing in my software is shared by anything else on the machine. I purposefully make sure not to place assemblies in the GAC. I have COM dlls (mix of old ActiveX, and newer COMVisible assemblies) that do get registered but that's only so they can be used by my application, if I could avoid that I would.
What I need to do is put files in directories and do some system stuff (dependency checking, environment variables, service, permissions, file associations, start menu items). And when I uninstall, get rid of all of that.
Maybe there is a better way than using a .MSI project for my use case?
Rather than having your installer manually registering files, Installshield has a "COM Extract at Build" option.
This will extract the COM data from the key file of the component, and that registry data will become part of the MSI. This means that the registry data is installed, uninstalled, repaired, modified and upgraded by the Windows Installer Engine - and not a custom action.
As a whole having your installer use native Windows Installer functionality will help it be cleaned up during an uninstall - if you have custom actions performing tasks at install time then these will have to be reversed with another custom action at uninstall time.
With regards to the shared components setting - we have a great article which explains why New Components are shared by default and what the "Shared" setting is actually doing.
