Jump to content

This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.

Why use SeflReg table?

3 replies to this topic


  • Members
  • 35 posts

Posted 04 July 2006 - 15:13

Granted this is only slightly technical topic but I have a feeling it will become non-technical pretty soon.

What is the point in using the SelfReg table instead of the advertising tables provided(Class, ProgId, TypeLib and sometimes Registry)?

For example I downloaded the MSJet 3.5 merge module today and all COM files were in the SelfReg table. Granted that all COM registry keys will get created but if some of them got deleted they would not be repaired correctly. I had to capture the COM information manually and move it to the Registry table and link to the correct MSJet components. In the downloadable DAO 3.51 merge module all registry keys were in the correct tables but both files were still registered via SelfReg table.

Isn't this also against MS Best Practises?

This is not a criticism but just a thought that is there a specific reason for sometimes using the SelfReg table?

And apologies for the typo in the heading... dry.gif

Edited by Petch, 04 July 2006 - 15:14.


  • Full Members
  • 522 posts

Posted 04 July 2006 - 19:26

I have one theory:

Some developers tend to add special functionality in the DLL-registration: for instance, creation of some extra registry keys. Usually the modifications are more sophisticated, like checking the existance of an NT service on WinNT, or nothing on Win9x.
If you have no access to the sources of the DLL, you have an alternative: let the DLL register itself.

BTW I recall that DAO 3.5 was deprecated in 1999 (with the arrival of Office 2000), so I can imagine that Microsoft never released a proper MSM.

Stefan Krueger

Stefan Krueger


  • Administrators
  • 13,269 posts

Posted 05 July 2006 - 07:27

There's one problem with the Clsid etc. tables: Entries are not only connected to a component but also tied to a feature. If you add them to multiple features, only one of these features will correctly install COM registration. But if only the other feature is selected you end up with incomplete entries.


  • Members
  • 35 posts

Posted 05 July 2006 - 10:15

Bordering off-topic but if that was the scenario then surely all common COM files should be in their own feature that gets always installed.

Sometimes you cannot use the advertising tables because of odd registration thats true but you could still use Registry table. For example one version of msvbvm60.dll file has /3 on the type library registration which cannot go into TypeLib table.