Register Library & Maintenance

[andrejzr]

Hi,

Installer for my application has several components, each one of them installing also several ActiveX libraries, that need to be registered/unregistered as selected.

Reading the posts in the forum, I see two ways how to handle the registration: either using the Register Library command, or importing the registry data and then manually writing entries to the registry.

Question 1: which method is recommended by InstallAware? What are benefits in each case?

Question 2 - related to the program maintanance:
In the help for the Register Library command, it says:
Files you self register with this command during an installation must be explicitly unregistered when they are being removed (such as deselection during an installation maintenance operation or a complete uninstallation).

How should this be handled in the script? Here I am giving an example of the process:
1. I make a full install, which has Component1 and Component2, registering DLL1 and DLL2 (one each)
2. I run install again - this time it will run in maintanance mode
3. I deselect the Component 2 (DLL2 should get unregistered)

How to write the script, that will know when to unregister DLL2?

Just checking the component state is possibly not enough, I see problems with:
- what if the Component 2 was not selected in first install (or I run the maintanance twice)?
- the DLL2 is a shared DLL, what means that it might be used by some other installation - shared count could not be 0. How do I know, when really the DLL can be unregistered?


Question 3: related to shared DLL files
I assume the Register Library command must be executed before Apply Install command - otherwise the DLL could be removed, and probably the Register Library command would fail. If so, how can the script know, what the file use count is in order to determine, if unregistering can take place?


I hope I was clear enough, your help is appreciated.

Thanks
Andrej

[MichaelNesmith]

Hi Andrej

I think in your case the correct approach would be to import the registry keys directly into the components associated with them. That would be the method with least effort and highest reliability.

[andrejzr]

Hi,

OK, I will use import registration data from the DLLs and use that for registering. What about the answers to the questionrelated to the shared DLLs? How should the script determine, whent it is appropriate to delete registration data?


Andrej.

[MichaelNesmith]

I guess then, what you can do is after Apply Uninstall, check if the DLL still exists on the system (its reference count hasn't reached zero, so its still got apps that are using/sharing it), and then at that point re-register the DLL using Register Library.

[andrejzr]

Hi,

Thanks for reply. Yes, this could work, although it doesn't seem a very clean solution to me

Just to verify:
- if a component is selected, I should add all WriteRegistry commands for component registration
- if a component is deselected, I should add all DeleteRegistry commands for component registration

Then I should run Apply Install command.

After the Apply install command, I should verify if the DLL still exists. If it does, I should apply the registration of the component again. Should I use the Register Library call at this point? I guess I cant use the Write Registry commands, since the Apply Install will not be called.

Can you confirm, that my thinking is correct? Or maybe point out, where things should be different.

Thank you
Andrej

[MichaelNesmith]

Upon reconsideration, I think its best if you only do the following: call Registery Library after Apply Install and the DLL exists, call Unregister Library before Appy Uninstall if DLL refcount is 1 (can be read from registry).

[andrejzr]

Hi,

Thanks for the information, but after studying the MSI documentation, I found the IA functionality related to shared ActiveX component registration quite limited.

The registration of the component and copying of the file should be handled in MSI under counting the shares of the MSI component, not just the file.

I am sure that you are familiar with WIX. There for example, you define a component:

<Component Id="COM_NAME", GUID="...", SharedDllRefCount="yes>

and inside the Component tag, you define the file:
<File>
Id="FileID"
Name="FileName"
...
</File>

AND all the registration registry entries:

<Registry .....>
<Registry .....>

and then close the Component tag

</Component>


This can be directly resembled in the MSI tables.

I don't see a way how this can be done using IA script. Since the Shared counting is done on a component level (and this is the way how native MSI recommends registering COM servers), there are no problems with registration/unregistration of the DLL.

It looks like IA doesn't suppor this fully, or it is just me missing something.


Any advice?


Regards
Andrej

[andrejzr]

Hi Michael,

I made some more research, and at the moment it seems, that it would be better for me to create merge modules for the shared components, where the registration would be done as described in my previous post. I would then include these merge modules into the IA script.

The drawback is that I can not bound the merge modules to the component selection state (as they are installed/deinstalled uncoditionally - correct me if I am wrong), but I guess I could live with this.

Can you confirm, that using the merge modules, created with WIX, and handling component registrations using the SharedDLLRefCount on the MSI component level, will be properly handled by IA?


Thanks again for your prompt answers.

Andrej.

[MichaelNesmith]

That's interesting research. Can you provide more details on how WiX actually passes the "shared COM" information to MSI files?

At any rate, you can definitely use the merge modules without problems.

[andrejzr]

Hello Michael,

I made a test creating a MSI using Wix, and creating a MSI using IA. Then I inspected both using the Orca tool.

If the shared component is defined for Wix as I pointed out in one of previous posts, one MSI Component is defined, and then the File entry and all registry entries belong to the same component.

When I checked the MSI generated by IA, each file and each registry key has its own MSI component generated - and this is not linking them together, and can not take advantage of the refcounting flag, that can be defined on the component.

As I see it, this is really quite big limitation of InstallAware, and probably you should pass the information to the product team to consider this.

My recomendation would be, that in InstallAware Write Registry command, there would be another option, that could lint it to a certain file. If this is done, then the File and Registry entries in the MSI would be defined under same MSI component. If the file is shared, this would automatically mean, that the registry key would not be removed in case the file is not removed. And as such solving the problem of registering the shared COM servers.

Let me know your thoughts.

Andrej.

[MichaelNesmith]

Thanks - will pass it on!

[andrejzr]

I made a test with the Register Library command, and checking the refcount before uninstallation - if 1 then calling Unregister library.

It is working, but there is one problem - the shared DLL file, that I want to remove (unregister is correctly called), is not deleted from the system. Instead, it is added to the PendingFileRenameOperations value in HKLM/SYSTEM/CurrentControlSet/Control/Session Manager key, and the files are only deleted after reboot of the machine.

Do you have any suggestions, why this is happening? As if the library would be in use at the time of remove. The last thing called prior to the Apply Uninstall are the Unregister library calls.

[MichaelNesmith]

It would appear the libraries remain active, hence are marked for removal on reboot. Might be a library issue?