Pourquoi l'auto-enregistrement est-il mauvais?

Question

En supposant que l’auto-enregistrement soit utilisé pour installer des composants dans le cadre d’un programme d’installation plus important, pourquoi l’auto-enregistrement est-il mauvais? Par exemple. auto-enregistrement de contrôles personnalisés vb ou capicom ou autre. Je reconnais que l’auto-inscription n’est probablement pas aussi sûre dans le cas d’une DLL que vous avez écrite vous-même, mais je ne discute pas de cela.

La liste MSDN répertorie plusieurs raisons . l'auto-inscription est incorrecte, reproduite ici:

La restauration ne fonctionne pas correctement.
OK, cette raison est logique.

La publication ne fonctionnera pas aussi bien.
Ignorant le fait que la publicité n'est importante que pour certains types de clients logiciels, je ne comprends pas pourquoi c'est un problème. Seule l’application principale doit être publiée, pas ses composants.

L'enregistrement automatique ne prend pas correctement en charge les clés par utilisateur.
Alors quoi? Donner à chaque utilisateur l'accès à " commun " composants n'est pas une mauvaise chose à moins d'avoir beaucoup d'utilisateurs sur la machine, auquel cas ce n'est pas encore la fin du monde.

L'auto-enregistrement est plus susceptible aux erreurs de codage.
Je peux vraiment y croire, sauf dans le cas des dll qui ont été écrites par Microsoft (elles peuvent avoir des erreurs, mais je ne pense pas que leur faire confiance soit déraisonnable). Et dans le cas des livres et des ocx générés par un logiciel, les erreurs de codage semblent plutôt improbables.

Les dll auto-enregistrées peuvent être liées à d'autres dll.
Dans le cas des dll générées par des programmes, il semble peu probable que l'enregistrement automatique échoue pour cette raison, mais l'ajout manuel des clés d'enregistrement aurait fonctionné. Je préférerais que mon auto-enregistrement retourne une erreur, à savoir qu'il me manque la DLL.

Je suis sûr que cela attirera des flammes: /

Éditer: les arguments barrés qui, à mon avis, importent (en fonction des réponses des utilisateurs et des miens).

    

Answer 1

En ce qui concerne cet élément:

  

  

• L'auto-inscription ne prend pas correctement en charge les clés par utilisateur.

       

  Alors quoi? Donner accès à chaque utilisateur   en " commun " composants n'est pas un mauvais   chose sauf si vous avez beaucoup d'utilisateurs   sur la machine, auquel cas c'est   toujours pas la fin du monde.

  

Le nombre d'utilisateurs sur une machine, mais également les autorisations dont ils disposent. S'il n'est pas administrateur, l'utilisateur ne sera probablement pas autorisé à mettre à jour la partie HKEY_LOCAL_MACHINE du registre.

Answer 2

L'élément

  

Les dll auto-enregistrées peuvent être liées à   autres dll

s'applique lorsque vous essayez d'enregistrer la dll, mais que le programme d'installation n'a pas encore copié / installé une autre dll requise par votre fonction d'enregistrement.

Answer 3

J'ajouterais un potentiel "gotcha" que j’ai rencontré (avec un code d’auto-enregistrement généré automatiquement pour les objets MS COM):

L’auto-inscription exécute l’exécutable, avec tout ce qui implique / requiert. Ainsi, par exemple, si votre composant enregistre directement ou indirectement le fait qu'il a été activé (peut-être pour la journalisation de la sécurité si le composant est censé s'exécuter uniquement à des points très spécifiques ou dans des contextes très spécifiques, ou en coordination avec d'autres applications), l'enregistrement semblera être une activation (à moins que vous ne fassiez attention à la journalisation). Cela peut également être intéressant si vos journaux enregistrent, par exemple, le contexte dans lequel le composant a été utilisé. Dans ce cas, vous aurez le même que le contexte hérité ayant déclenché l’auto-enregistrement.

Ce n’est pas grave dans la plupart des cas, mais cela peut parfois créer une confusion subtile. Je l'ajouterais à la liste des raisons pour lesquelles ce n'est probablement pas préférable.