How should I handle registration?
I've received a vendor MSI which includes some public DLL/OCXs which are in the self-reg table. However, the selfreg doesn't work properly.
I've seen it mentioned on these forums before that the best-practice method is to capture the registration then import it into the registry table. So, my question is, a) how should I structure this in the MSI (ie components), and b) how does registration work as part of version control?
So far, I've bulk imported the necessary registration into the MSI, then assoicated it all with the same component. I've then made this component permanent. Is this a good idea? The thinking behind this was that if the MSI is uninstalled, the DLL will remain installed if the refcount>1, but since there's no version control on the registry, how is registration maintained? Or is registration reliant upon MSIs self-repair capability. If a DLLs refcount is >1 at uninstall, is it just the file that remains installed, or is it the component? If this were the case, I guess I'd associate each registration registry entry with the DLL file component.
I've seen it mentioned on these forums before that the best-practice method is to capture the registration then import it into the registry table. So, my question is, a) how should I structure this in the MSI (ie components), and b) how does registration work as part of version control?
So far, I've bulk imported the necessary registration into the MSI, then assoicated it all with the same component. I've then made this component permanent. Is this a good idea? The thinking behind this was that if the MSI is uninstalled, the DLL will remain installed if the refcount>1, but since there's no version control on the registry, how is registration maintained? Or is registration reliant upon MSIs self-repair capability. If a DLLs refcount is >1 at uninstall, is it just the file that remains installed, or is it the component? If this were the case, I guess I'd associate each registration registry entry with the DLL file component.
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
williamp
18 years ago
My understanding is that refcounts are kept for the key file in a given component, and that what is done with the key file is done with all the other resources in that particular component. Including registry entries. In other words, resources are installed or uninstalled by Windows Installer with the component as the smallest granular object, with refcounts maintained on the component's key file. So, if you have included registry entries in a component, you may expect them to be retained as long as - but no longer than - the component key file is retained.
That being said, any given dll, exe, ocx, etc. file which has registry data, should each be given its own unique component, and then be made the key file for it. Then put each particular file's associated registry data into the respective component having the file.
I hope this is written clearly enough to be useful.
Regards,
William
That being said, any given dll, exe, ocx, etc. file which has registry data, should each be given its own unique component, and then be made the key file for it. Then put each particular file's associated registry data into the respective component having the file.
I hope this is written clearly enough to be useful.
Regards,
William
ORIGINAL: meastaugh1
So far, I've bulk imported the necessary registration into the MSI, then assoicated it all with the same component. I've then made this component permanent. Is this a good idea? The thinking behind this was that if the MSI is uninstalled, the DLL will remain installed if the refcount>1, but since there's no version control on the registry, how is registration maintained? Or is registration reliant upon MSIs self-repair capability. If a DLLs refcount is >1 at uninstall, is it just the file that remains installed, or is it the component? If this were the case, I guess I'd associate each registration registry entry with the DLL file component.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.