DllRegister Considered Harmful
When creating Windows installers, it is quite common to want to register COM DLL’s, install services, register MMC snap-ins and what have you. If you were doing this manually on your development machine, you would most likely use one of the automated methods of registration — namely DllRegisterServer or a managed installer. However, when creating a Windows installer this is the wrong thing to do. Here’s why.
Let’s say you create an installation that copies a COM DLL to the user’s system and registers it in the registry using DllRegisterServer. You also have a custom action to unregister the DLL upon uninstall.
Now let’s say another application is installed which uses the same component (COM DLL). The Windows Installer service has reference counted your installations of this file and knows that there are now two products that depend on it. Subsequently, the user uninstalls your product. What do you think will happen?
The result will be a COM DLL still sitting on the user’s disk but no longer registered with the system. The problem is that Windows Installer can reference count components and resources, but it doesn’t have a damned clue what you’re doing when you run code.
The moral of this story is to register components by using the registry table or the serviceInstaller table built into the Windows Installer infrastructure. Installer’s rollback and conflict resolution magic only works on resources — not code.
Write a comment