3 replies to this topic

[MillionsterNutzer]

Hi!

I´ve got two Setups that both bring the same COM-dll with them. In both Setups the dll is registered via selfRegistration.
The problem is, that when one of my products gets uninstalled the remaining one won´t work anymore, because the registration of the COM-dll is gone. Strange is that the setups are smart enough to recognize that the dll was installed by another product, but they are not smart enough to recognize that the dll was also registered by another product.

I could simply tell the setup not to uninstall the dll on Uninstall, but that would mean that it would always remain on the target system. The dll and its registration should only removed if both products will be removed.

Is there a way to tell the setup not to unregister the dll on Uninstall? Or is there any other way to solve my problem?

Regards

MillionsterNutzer

[Maharani]

Have you tried defining the dll as a potentially shared file? I don't know whether this would avoid unregistering while uninstalling but it might be worth a try.
Another approach would be defining the dll not as self-registering and register the dll manually (maybe with LaunchAppAndWait with regsvr32.exe and appropriate command line parameters) in the On_Installed event handler of the corresponding feature.
Although this means that you leave an orphaned registry entry after uninstalling both applications which is not the end of the world but it's not nice.

Btw: Do you install the dll into the same target folder for both apps?

Regards
Rita

[MillionsterNutzer]

Hi Rita!

I guess you were right with setting the dll as an "potentially shared file", but actually the circumstances are a bit more complicated than I told in my first post.

First I have to admit that for both products (let´s call them AA and BB) the 'bad' setups have already been released for example for Version 1.0 (actually there was more than one release) and our customers are already using our products without knowing that the uninstall of AA will end in some erros with BB. Not nice but I can´t change that.

Second: Now I´m up to release Setups for Version 2.0 of my products and funny is that now as this problem is reported by my testers the problem doesn´t exist for this version directly because Version 2.0 of AA doesn´t need the COM-dll anymore.

But there is one exception: If my customers will UPDATE their products from 1.0 to 2.0 they will still have the problem that in case of an Uninstall of product AA InstallShield still has the uninstall information from Version 1.0 so the COM-dll is still removed althought it doesn´t need it since the update.

A strange situation insn´t it?

I´ve played around with version 2.0 of my Setups:

- I tried to register the file with regsvr32 on uninstall, but this code seems be never reached. I guess this is because of the update from 1.0

- I tried to bring and register the DLL with a new component, telling IS it is a shared file and to not uninstall it => No success. So I guess once againg the old uninstall information is executed and unregisters the dll.

- I tried to use XCopy with the SHAREDFILE option => Once again no success.

I guess my only hope would be to modify the uninstall information of the old 1.0 setup when updating to 2.0.

Is there a way to do this?

Regards

MillionsterNutzer

PS: Yes the dll is copied to the same target folder in both setups.

[Maharani]

Actually your problem disturbs me a bit, too - we have 3 apps (AA, BB and CC) which can be installed on the system in various combinations. They share a few components as well, including com components.
We do not use a common folder, each app installs itself in a separate folder by default.

Of course this means that when uninstalling one component a com component which was registered in that app's folder will be unregistered (which is perfectly correct, of course) without registering it from the place of the other app (the existence or non-existence of AA is unknown to setup of BB or CC anyway - setup at this site is done on top of the actual programming so I try not to dive too deep into IS).

We had several other issues with COM registration anyway, settings were lost in a non-replicable manner sometimes etc. What I did was not solving possibly occuring issues in all possible combinations of install/update/unistall processes of our various apps but provide a simple way to deal with problems in case of emergency.

At the end of each install or update my 3 setups will create two batch files "RegisterAA.bat" and "UnregisterAA.bat" in the target dir of AA (and BB and CC as well). Depending on the installed features it contains the necessary commands to register/unregister the exe or dll servers installed by this feature. On Uninstall these files are removed. The apps name was necessary for the (unrecommended and unlikely) case that somebody installs all apps into one target folder - in this case you have the 3 batch files nevertheless.

So, if ever a customer should run into a problem with corrupted registration entries we can tell him "Start the RegisterAA.bat file in the installation directory".
It's not really a solution, just a workaround. But if you have such a file you could even check the existence of an app AA installation when uninstalling BB via registry uninstall information and try to run the batch file of AA when you find it.

About manipulating uninstall information of previous versions - I have no idea. These are things I hopefully never have to know about IS.

Still, you could try to make sure that nobody updates from other versions by checking version and deny update with a "This version can't be updated, please unstall first" message. But this, of course, is nasty. We did it once or twice after really big software structure changes when it was unavoidable and everything else had to be redone anyway.

Well, I see that none of this really helps you.

Good luck anyway
Rita