"dependent" component?

[Matthias1967]

Hello,

I am writing MSI setups for several applications that share some components.

One of these components got an additional DLL dependency in the current version. Of course, I added that DLL as a new component.

Now consider the following scenario:
User has two applications of ours installed, one of them using the newest version of the shared component, one of them using an older version of the shared component. This results in the shared component being installed in the newest version, and the adiditional DLL being present.

Now the user uninstalls the application that has brought the newest version of the shared component. As a result, the shared component remains on the computer (since it is still referenced by the other application) in its newest version. But the additional component is gone, because the application just uninstalled was its only reference. So this shared component cannot be used any more!

As of now, I see basically two solutions, both of which look ugly to me:
1) Never add a dependency to a shared component - I do not think that app developers will ever comply with this
2) make that "new" DLL a permanent component - this means it will remain there even after uninstall, even if no more needed at all

Any other ideas?

Best regards

Matthias

[enanrum]

Hmmm...tough one. Perhaps the following may work. I'm sure there is a way to get the SharedDll count from the registry for the shared Component, set this count to a property, ie SHAREDDLLCOUNT.

Add a condition on the new dll component, SOMEFLAG, and default it to 1 (set it in Prop Manager "SOMEFLAG= 1".) Create a Custom Action, "Set Property: SOMEFLAG = 0." Add the CA in the sequence and add the condition "REMOVE AND SHAREDDLLCOUNT > 1"

The condition of the shared dll would be false and would not be uninstalled.

You maybe able to get the SharedDLL count using the "Behavior and Logic->System Search" - I use it to get reg entries but never tried for SharedDll count:

Search For: [INSTALLDIR]\your\dll (yes you can use properties in here)

Search In:[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls]

Store In: SHAREDLLCOUNT

its a dword so not sure how it sets the property - test it out.

Hope this helps - regards

[Matthias1967]

Hello enanrum,

thank you very much for that idea! I have implemented a different solution, which works so far - at least for my purposes:

I schedule a CA "KeepDependencies" after InstalllValidate.
I keep track of those suspicious dependencies myself - either hard-coded in the CA or by a custom table.

The CA checks whether the dependency is to be removed (I call MsiGetComponentState on the Dependency and evaluate nvActionStateDep = INSTALLSTATE_ABSENT) - I do not use condition on the CA here because there may be more than one entry in the dependencies list.

If so, I check the ComponentState of the parent component. If this is to be kept (or installed) (nvInstallStateParent != INSTALLSTATE_ABSENT && nvActionStateParent != INSTALLSTATE_ABSENT), I set the action state of the dependency to local:
MsiSetComponentState(hMSI,svDependency,INSTALLSTATE_LOCAL);

The intention of my post was rather to ask whether Windows Installer has some "built-in" solution for this issue - from your reply, I think there is really none...

Best regards

Matthias