Comment résoudre la classe d'exception COM non enregistrée (exception de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))?
Lorsque j'essaie de créer une instance d'une classe COM, une exception est générée.
Classe non enregistrée (exception de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
S'il vous plaît suggérer comment puis-je le résoudre?
Il semble que tout programme ou processus que vous essayez d'initialiser soit n'est pas installé sur votre ordinateur, a une installation endommagée ou doit être enregistré.
Installez-le, réparez-le (via Ajout/Suppression de programmes) ou enregistrez-le (via Regsvr32.exe).
Vous n'avez pas fourni suffisamment d'informations pour que nous puissions vous aider davantage.
Vous devez vous assurer que tous vos assemblys sont en train de compiler pour une architecture correcte. Essayez de changer l'architecture pour x86 si la réinstallation du composant COM ne fonctionne pas.
Mon problème et la solution
J'ai un dll tiers 32 bits que j'ai installé en 2008 R2 machine qui est de 64 bits.
J'ai un service de wcf créé dans le cadre de .net 4.5 qui appelle la DLL tierce de 32 bits pour le processus. Maintenant, j'ai défini la propriété de construction pour cibler «n'importe quel» processeur et je l'ai déployé sur la machine 64 bits.
lorsque j'ai essayé d'appeler le service wcf, j'ai obtenu une erreur "80040154 Classe non enregistrée (exception de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG")
Maintenant, j'ai utilisé ProcMon.exe pour suivre le problème du registre com et j'ai identifié que le processus recherche l'entrée de registre sous HKLM\CLSID et HKCR\CLSID où il n'y a pas d'entrée.
Sachez que Microsoft n'enregistrera pas les composants com 32 bits dans les chemins HKLM\CLSID, HKCR\CLSID dans une machine 64 bits, mais placera l'entrée dans les chemins HKLM\Wow6432Node\CLSID et HKCR\Wow6432Node\CLSID.
Désormais, le conflit est un processus 64 bits qui tente d’appeler un processus 32 bits sur un ordinateur 64 bits qui recherche l’entrée de registre dans HKLM\CLSID, HKCR\CLSID. La solution est de forcer le processus 64 bits à examiner l'entrée de registre sous HKLM\Wow6432Node\CLSID et HKCR\Wow6432Node\CLSID.
Cela peut être réalisé en configurant les propriétés du projet de service wcf pour qu'elles ciblent la machine 'X86' au lieu de 'N'importe lequel'.
Après le déploiement de la version 'X86' sur le serveur 2008 R2, le problème "System.BadImageFormatException: Impossible de charger le fichier ou l'assembly".
La solution à cette exception badimageformatexception consiste à définir le paramètre 'Enable32bitApplications' sur 'True' dans les propriétés IIS Apppool du bon pool d'appels.
Notez également que le contexte de la classe lors de l'initialisation peut créer cette exception. Si vous avez un objet codé comme INPROC_SERVER mais que vous essayez de co-créerInstance sous le nom CLSCTX_LOCAL_SERVER, vous obtiendrez également cette erreur.
Vous devez vous assurer que l'objet est enregistré et que CoCreateInstance crée une instance avec le contexte de classe correct.
Si vous utilisez des composants COM 64 bits dans une application Web sur IIS, vérifiez que le pool d'applications est défini pour ne pas autoriser les applications 32 bits ( Activer les applications 32 bits: false dans les paramètres avancés)
Je l'ai obtenu en activant les applications 32 bits dans les paramètres avancés du pool d'applications. Faites un clic droit sur le pool d'applications et choisissez les paramètres avancés - activez les applications 32 bits .Cela peut aider quelqu'un.
En enregistrant la classe (en particulier son CLSID) - voir par exemple ici .
J'ai résolu ce problème en enregistrant la COM via regsvr32.
assurez-vous que le COM que vous invoquez est enregistré.
Mon application utilisait xceedcry.dll et je ne l'enregistrais pas. Une fois que je l'ai enregistré, l'application a bien fonctionné.
dans mon cas
my platform est x64
the Dll library(sdk) et le redistributable package est x64
alors
dans l'explorateur de solution
navigate to your projectouvert
Propertieschange the Platform target from AnyCPU to x64
Pour moi, je devais créer une configuration de construction 64 bits.
Ma solution a été de remplacer "Activer les applications 32 bits" par True dans les paramètres avancés du pool d'applications relatif dans IIS.
Dans mon cas, la classe a été enregistrée correctement et construite en mode ANY CPU/64 bit.
Toutefois, la propriété Activer les applications 32 bits du pool d'applications IIS de l'application qui utilise la classe a été définie sur True.
La classe n'a pas été trouvée en raison d'une incompatibilité d'architecture entre la configuration du pool d'applications et la classe enregistrée réelle.
Le réglage de Activer les applications 32 bits sur False a résolu le problème . 
J'ai rencontré ce problème en appelant un assemblage .Net à partir d'un client C++ via COM. Il s’avère qu’une des assemblées dont dépendait l’assemblée .Net n’avait pas pu être trouvée. J'ai longtemps lutté pour essayer de comprendre ce qui n'allait pas avec la 1ère Assemblée, mais c'était en réalité l'une des dépendances de la 1ère Assemblée. J'ai reçu deux erreurs différentes lors de l'appel de CoCreateInstance () à partir du client C++. La première était: REGDB_E_CLASSNOTREG Classe non enregistrée Et la deuxième tentative était: 0x80131040: La définition du manifeste de l'assembly localisé ne correspond pas à la référence de l'assembly.
Vérifiez donc que les références de votre assemblée sont présentes ... J'ai découvert ceci en parcourant la 1ère assemblée avec dotPeek et en remarquant qu'il manquait l'une de ses références. Placer la version correcte de la dépendance dans le dossier a résolu les deux erreurs.
Je compilais mon application ciblant n’importe quel processeur et le problème principal s’est avéré que le lecteur Adobe était installé plus ancien v10.x nécessite de mettre à niveau v11.x , c’est ainsi que Je parviens à résoudre ce problème.
J'ai fait face au même problème. Après avoir fait quelques recherches, j'ai trouvé des solutions pour moi et cela pourrait être utile. Le problème ne concerne pas seulement la réinstallation à compter de mon observation, il dépend également des autorisations d'accès.
Étape 1: Réparez l'objet COM particulier.
Étape 2: Services de composants> Ordinateurs> Poste de travail> Configuration DCOM> Sélectionnez votre objet COM> Clic droit> Propriétés> onglet Sécurité> Autorisations d'accès> Personnaliser> Cliquez sur MODIFIER> Sélectionner IUS_USER (s'il n'existe pas, créez-le avec tous les droits) accéder et cliquez sur OK.
Déplacer vers l'identité> Vous pouvez sélectionner "Utilisateur interactif" ou "Cet utilisateur"> Cliquez sur Appliquer, puis sur OK. Si vous choisissez "Cet utilisateur", nous devons attribuer à ce serveur des privilèges administratifs.
Étape 3: Ouvrez le gestionnaire IIS> Redémarrez les pools d'applications.
Remarque: Si nécessaire, redémarrez le serveur.
J'ai rencontré le même problème en utilisant une classe COM, c'est-à-dire "Exception de classe non enregistrée" au moment de l'exécution. Pour moi, j'ai pu résoudre le problème en accédant au fichier app.config et en modifiant les éléments 'startup' et 'supportedRuntime' en quelque chose comme:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Vous pouvez en savoir plus sur les détails ici http://stackoverflow.com/questions/1604663/
et ici https://msdn.Microsoft.com/en-us/library/w4atty68(v=vs.110).aspx
Je dois noter que j'exécute Visual Studio 2017 . Cpu cible = x86 Type d'interopérabilité incorporé = true (dans la fenêtre des propriétés)
J'avais le même problème avec MapWinGis . J'ai trouvé la solution en travaillant sur proyect de visual studio 2015, il suffit de cliquer avec le bouton droit de la souris sur le projet-> Propriétés-> Construire, de définir la configuration sur Toutes les configurations et dans la cible de la plate-forme conbobox "le mettre à x64.
accédez au répertoire de .Net Framework et enregistrez leur dll respective avec Regsvr32.exe white space dll path.