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.
Photo

To self-register or not...


8 replies to this topic

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 11 January 2006 - 13:48

The products I'm installing are a mix of VB and VB.Net and all have a mixed bag of DLLs, some of which can be self-registering.

Is it recommened to:

- select to self-register (I'm using Wise but I imagine InstallShield etc would have a similar capability)
- call RegSvr32/RegAsm in script/CA, or
- simply add the relevant fluff to the Registry table?

It's obviously quicker and simpler to do the first one but in trawling through the forums, I variously see the other options as being preferred.
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 11 January 2006 - 21:00

Windows Installer has special tables for COM components. For a discussion see http://msdn.microsof...lfreg_table.asp

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 12 January 2006 - 10:31

Thanks for the reply, Stefan, but it doesn't really answer the question.

My problem with populating tables is that it becomes an maintenance nightmare when objects change, as they frequently do at the client where I'm currently working.

At previous clients, OCXs, DLLs, TLBs, etc were ALWAYS registered with RegSvr32/RegTLib/RegAsm; this client doesn't have a standard and previous packagers seem understandably to have pleased themselves about how they've handled this one.

However, if you're saying that the table route is the recommended one, then I'm stuck with it. The question then becomes, if that's the recommended route, why do the packaging products include facilities to have DLLs etc self-registered? (rhetorical question)
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 12 January 2006 - 15:43

Because there may be situation where the tables aren't feasible, or you don't have the data available that you need to populate them. Many MSI authoring tools have an option to automatically extract the self registration information from files and populate these tables for you. This can be refreshed for each build.

Note that some MSI experts recommend not using the Class etc. tables but the registry table instead because the resiliency fuctionality for COM registration sometimes causes more problems than it's worth. But the Registry table is still preferred over self-reg. You just have to ignore the validation warnings this generates smile.gif

When using the registry table you could ask the developers of the COM files to provide .reg files with the required registration information which you then can import into your project (if your authoring tool supports this)

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 13 January 2006 - 00:07

This sounds interesting. What is the reason these experts recommend using the Registry table?
Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 16 January 2006 - 12:41

Rob Mensching (author of Orca and WiX) is advocating against it, like here and here. I think I've also seen/heard members of the MSI team questioning if it was a good decision to have advertisement and resilience for COM classes.
However to avoid any confusion: Using the Class, ProgId and related tables is still the officially recommended way today. I just wanted to mention that there is a debate questioning this but without manifest results yet.
One of the problems I experienced myself is that COM registration is connected to a specific one feature(!). As a result if that component is connected to multiple fetuares you may end up with missing COM data in registry.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 04 March 2006 - 10:19

Hi Stefan, thanks for that information. I am currently discussing the same issue for a WIX based automatic MSI generator tool that we are creating in a project at work at the moment.

Some minor side effects though:
  • For per user installs COM data should be written to HKCU\Classes. This would not work with data in the registry table, would it? The data should still be installed, but per machine. Probably not a big deal.
  • If the install is advertised and another app invokes a COM server it installed, no self repair would occur. I guess this is the primary reason why the COM data is advertised in the MSI in the first place.
  • I suppose your application could get more vulnarable to sloppy installs that corrupt the COM registry data.

That being said, the overall problem is the overall design of COM itself. Who came up with that stuff?
Regards
-Stein Åsmul

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 06 March 2006 - 16:31

QUOTE
For per user installs COM data should be written to HKCU\Classes. This would not work with data in the registry table, would it? The data should still be installed, but per machine. Probably not a big deal.

With the Root column in the Registry table set to -1 your entries go to HKCU or HKLM depending on the value of the ALLUSERS property.

QUOTE
If the install is advertised and another app invokes a COM server it installed, no self repair would occur. I guess this is the primary reason why the COM data is advertised in the MSI in the first place.

Yes, and that's what the current debate is about: whether it's really necessary to support auto-repair and install-on-demand for COM activation, or if this causes more trouble than it's worth.

Glytzhkof

Glytzhkof
  • Moderators
  • 1,447 posts

Posted 06 March 2006 - 17:29

Indeed that is what the discussion is about, and I actually find that self repair for COM components provide benefits when I am doing application repackaging in a corporate environment. When we have families of products it is not uncommon for them to call COM servers installed by another setups. Hence it is good when using advertised and published setups to ensure that they install properly on demand.

That being said COM certainly cause problems, but I'd say the overall problem is the COM technology itself and not MSI. It is riduculous that so many registry entries and files must be in sync for a COM server to work correctly.
Regards
-Stein Åsmul