+1  A: 

As far as this item:

  • Self-registration does not support per-user keys properly.

    So what? Giving every user access to "common" components is not a bad thing unless you have a lot of users on the machine, in which case it's still not world-ending.

It's not just a matter of how many users are on a machine, but also what permissions they have. If not an administrator, the user will be unlikely to have permission to update the HKEY_LOCAL_MACHINE portion of the registry.

Michael Burr
A: 

The item

Self-registering dlls may link to other dlls

applies when you try to register the dll, but the installer has not yet copied/installed another dll your registering function requires.

Stefan
A: 

I would add one potential "gotcha" which I have run into (with auto-generated self-registration code for MS COM objects):

Self-registration runs the executable, with all that entails/requires. So, for example, if your component directly or indirectly logs the fact that it was activated (perhaps for security logging if the component is only supposed to be running at very specific points or in very specific contexts, or in coordination with other applications), registration will appear to be an activation (unless you're careful about logging). This can also be interesting if your logs record, say, the context in which the component was utilized, in which case you will have whatever inherited context triggered the self-registration.

Not a big deal in most cases, but it can cause some subtle confusion sometimes. I'd add it to the list of reasons why it's probably not preferable.

Nick
I'll agree this is a gotcha but I don't consider this an argument against self-registration.
Brian