Why is selfregistration bad?

Question

Assuming self-registration is used to install components as part of a larger installer program, why is self-registration bad? E.g. self-registering vb custom controls or capicom or whatever. I acknowledge that self-registration is probably not as safe in the case of a dll you wrote yourself, but I'm not discussing those.

The MSDN lists several reasons why self-registration is bad, reproduced here:

Rollback won't work properly.
OK, this reason makes sense.

Advertisement will not work as well.
Ignoring the fact that advertisement is only important for certain types of software clients, I don't understand why this is an issue. Only the main application needs to be advertised, not its components.

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.

Self-registration is more susceptible to coding errors.
I can definitely believe this, except in the case of dlls which were written by Microsoft (they may have errors, but I don't think trusting them is unreasonable). And in the case of tlbs and ocxs which were generated by software, coding errors seem pretty unlikely.

Self-registering dlls may link to other dlls.
In the case of dlls generated by programs, it doesn't seem likely that self-registration will fail due to this but adding the registration keys manually would have worked. I'd rather have my self-registration return an error that I'm missing the dlls.

I'm sure this will draw flames :/

Edit: Crossed out arguments that I think actually matter (based on user responses and my own).

Answer 1

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.

Answer 2

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.

Answer 3

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.