5 replies to this topic

[Ballall]

Cannot make a new CA dll to run when upgrading.

I need to rebuild my CA dll:s for each new version of my installer.

The CA:s runs works perfectly well when I manually uninstall previous version and then run the installer of the new version.

It also works if previous version is automatically removed by the installer AND the path where I install the CA dll:s are different from the previous version.

A guess is that the installer software simply loads the old dll (in memory) at the uninstall phase and then when installing the new one, it uses the old dll.

Debugging the installer confirms this and shows that there is two CA dll:s loaded and one of them have a mismatched timestamp.

I've tried to change version of the new CA dll without result.

Does anyone know how to solve this? I don't want to change the dll name for each new version of my installer.

Edited by Ballall, 07 October 2004 - 15:33.

[Stefan Krueger]

Yes, I guess it wouldn't load two instances (versions) of the same dll (same name) in one process.

[Ballall]

Thanks, seems like I'm someway on track then.

However, this implies that you can NEVER change your CA dll and have the installer to automatically remove previous versions.

It simply cannot be that bad. Am I the first person ever changing the CA dll? There must be a way to handle this or at least there should be some workaround apart from changing the dll name.

Anyone, please!

[Zweitze]

InstallShield (I assume you use that) has two kinds of DLL CAs, "Call a function in a standard dynamic-link library" and "Call a function in a Windows Installer dynamic-link library".

If you created a "Windows Installer DLL", you should have no problem. Windows Installer loads and unloads the DLL for each custom action. Therefore, you can change the inner working of the DLL with a new version.

I found problems with the implementation of "standard DLL", at least with ISWI 1.52. What happens is: InstallShield adds its own handler, which is called at the beginning. This handler extracts a temporary file, that contains all functions and parameters lists. Unfortunately, the name of this file is hardcoded (I believe "DLL.INI"). In my case, the setup could be a major upgrade, so DLL.INI was extracted twice, and they did overwrite each other. I changed the parameters of one function, and ran in problems.

When I understood the inner working of "standard DLL", I immediatly changed all DLLs to support "Windows Installer CAs". Never had a problem since.

[Ballall]

I'm using the .NET installer, not InstallShield (yet), so I'm not sure it populates the database with the right things regarding the updated CA:s.

[Stefan Krueger]

Support for "standard dlls" is only in InstallShield, so this is probably not your problem.