Il s'agit probablement d'une dépendance, mais Visual Studio doit tenter de les ajouter à votre projet d'installation, du moins ceux qu'il peut détecter à partir des informations de manifeste d'assembly. VS ne détectera pas les dépendances COM car il n'y a rien qui indique à quelle DLL vous lierez au moment de l'exécution. En outre, si vous avez installé un assembly dans le GAC et que votre DLL en dépend, cela provoquera également l'échec. Les assemblys ne sont pas dans le GAC jusqu'à la phase Commit, donc une action personnalisée Commit fonctionne parfois.
L'autre problème est que votre assembly n'est pas chargé de la manière habituelle. Il est instancié avec la réflexion, puis essaie de localiser les classes de l'installateur (d'où le message) et cela contourne toute redirection et ainsi de suite.
Il peut également y avoir une discordance d'architecture. Si votre Dll est AnyCpu et qu'il fonctionne en mode 64 bits, tous les assemblages dépendants de 32 bits ne seront pas chargés. Le Fusion Log Viewer peut être utile pour identifier la dépendance manquante.
Si cette DLL contient des formulaires et des commandes que vous allez montrer pendant l'installation, ce n'est généralement pas la bonne chose à faire. Vous ne serez jamais capable de faire une installation silencieuse, les formulaires/contrôles ne fonctionnent souvent pas correctement (vous n'êtes pas en cours d'exécution dans l'environnement approprié pour une boucle de message Windows UI). En outre, la sécurité de Windows peut l'empêcher de s'afficher car votre action personnalisée sera (probablement) exécutée avec le compte système et afficher l'interface utilisateur, ce qui est la même raison pour laquelle les services interagir avec les postes de travail sont obsolètes. Donc, si vous faites une configuration, faites-le à partir d'une application utilisateur normale la première fois que l'application fonctionne.