Software Deployment

Is the old package in the form of MSI? If so, you can use that (copy) and make an upgrade for existing package so including the dll files into the package making up the upgrade.

The old package is an InstallShield 6.3... using some InstallScript and other InstallShieldThings, that's why I must build MSI compliant packages :-).

But I maybe found a solution which could solve my problem, using some reboot after the uninstall process.
The problem I have, is when I use MajorUpgrade. The uninstall process end with a reboot (that's ok) but I would like to make it AUTOMATIC (don't prompt some boxs) and that the upgrade process runs automatically after the reboot, at the same point that it was before...

I'm looking for REBOOT and REBOOTPROMPT use...

Thank you for your efforts AngelD !

So if i understand you right you don't want to remove the dll:s if the other product is installed and shouldn't be uninstalled?

If that's the case that shouldn't be a problem due to the SharedDll reference counter.

And as BestPractise, you shouldn't uninstall files installed to the System32 directory. The component(s) holding this/these file should be set to msidbComponentAttributesPermanent.

I already set the SharedDll (I hope...), and... that didn't change anything !!

Moreover, I don't want that Dlls to be on the computer if I remove the product, I would like to clean up all my files.

And finally, what I really would like is to show to the user WHAT services/programs are using these Dlls, in order him to know the consequences of the uninstall process.

Not so easy for me [:(]

If the SharedDll counter setting is correct the user "don't have to" know/or be informed if that component/file is used by another application as this will be a hidden "action" and the uninstallation process will not remove that file/dll.

I'm sorry, but look at my component table, I have the SharedDll bit set :




When I install the DLL_product, the DLLs are copied to the System Folder.
When I install a Service Product and that it is running, it uses these DLLs.
When I want to delete manually these DLLs whereas they are NOT being used by a service (or something else), I can do it.
When I want to delete manually these DLLs whereas they are being used by a service, I can't do it.
When I uninstall the DD_product whereas the DLLs are being used by a service, they are deleted !

So, I have 2 solutions :

The best one is to prevent the user that ProgramX, ServiceY, ... are using files which are to be deleted. Windows installer do it perfectly for Programs, but not for Services ! How can I do that ?
The second solution would be not to delete some of the files before next reboot, but I don't know how to force it. Using the default MSI way, files are deleted...

Hope you understand my problem, I don't speak really well [;)]

sorry but have to ask, is the shareddll bit set in both packages?

MMmmh, the second package (Service_product) uses but don't install these DLLs, so I think that no bits are set in it...

I can't say it to you because I didn't build the Service_Product Package...

the second package (Service_product) uses but don't install these DLLs, so I think that no bits are set in it...If the files are include in this packages and they already exist (same version) on the computer, they will not get installed but they will increase the reference counter of 1 anyway if the bit is set.

Both packages must have this set for the DLL files so they can each add themself to the reference counter.
For ex. say that only these packages/applications install/uses the DLL files, there will be a reference counter of 2 when both has been installed. When one of the package is uninstalled/removed the counter will go down to 1 and the files will not be removed due to requirement of reference counter will have to be set to 0 if this should happen. When the last application is uninstalled/removed the counter will go down to 0 and is safe for removal.

If the service package is an MSI installation, just open it and verify. You could create an MST for this change if that is required for the service package and redeploy it, this should solve your problem.

I'm working on new installers, but they must work with old installers which don't have this component (DLLs) included... that's the problem...

I can't use the reference counter ! :-(