La récupération de la fabrique de classes COM pour le composant avec CLSID {XXXX} a échoué en raison de l’erreur suivante: 80040154

Dans VS – propriétés du projet – dans l’onglet Build – cible de la plate-forme = X86

Il semblerait que votre service ait été construit sur «N’importe quel processeur», ce qui vous a causé des erreurs sur 64 bits lorsque vous utilisez des composants COM. Vous devez le construire pour x86 .

Le site Web fonctionne probablement comme un processus 32 bits, ce qui explique pourquoi il peut utiliser le composant. Construire votre solution contre x86 forcera votre service à fonctionner en 32 bits.

J’ai rencontré un problème très similaire.

Je devais utiliser une ancienne DLL 32 bits dans une application Web en cours de développement sur une machine 64 bits. J’ai enregistré la DLL 32 bits dans le dossier windows \ sysWOW64 en utilisant la version de regsrv32 dans ce dossier.

Les appels à la DLL tierce partie ont fonctionné à partir de tests unitaires dans Visual Studio, mais ont échoué à l’application Web hébergée dans IIS sur le même ordinateur avec l’erreur 80040154.

La modification du pool d’applications en “Activer les applications 32 bits” a résolu le problème.

Le problème est que le processus du serveur est 64 bits et que la bibliothèque est 32 bits et qu’il essaie de créer le composant COM dans le même processus (serveur in-proc). Vous pouvez soit recomstackr le serveur et le rendre 32 bits, soit laisser le serveur inchangé et rendre le composant COM hors processus. La méthode la plus simple pour rendre un serveur COM hors processus consiste à créer une application COM + – Panneau de configuration -> Outils d’administration -> ComponentServices.

Si vous cherchez un moyen de faire ce travail sans recomstackr votre application Any CPU, voici une autre solution possible:

1. Recherchez votre GUID d’object COM sous le HKey_Classes_Root \ Wow6432Node \ CLSID \ {GUID}
2. Une fois localisé, ajoutez une nouvelle valeur REG_SZ (chaîne). Nom doit être AppID et les données doivent être le même object COM GUID que vous venez de rechercher
3. Ajoutez une nouvelle clé sous HKey_Classes_Root \ Wow6432Node \ AppID. La nouvelle clé doit être appelée comme le GUID de l’object COM.
4. Sous la nouvelle clé que vous venez d’append, ajoutez une nouvelle valeur de chaîne et appelez-la DllSurrogate. Laissez la valeur vide.
5. Créez une nouvelle clé sous HKey_Local_Machine \ Software \ Classes \ AppID \ Encore une fois, la nouvelle clé doit être appelée de la même manière que le GUID de l’object COM. Aucune valeur ne doit être ajoutée sous cette clé.

Je ne prends aucun crédit pour la solution, mais cela a fonctionné pour nous. Consultez le lien source pour plus d’informations et d’autres commentaires.

Source: http://www.gfi.com/blog/32bit-object-64bit-environment/

Vous n’avez pas besoin de configurer la cible X86 de votre plate-forme de propriétés de projet. Vous pouvez également configurer les options iis pour travailler avec x86 comme ça

• Sélectionnez le pool d’applications
• Sélectionnez le pool que votre application utilise
• Réglages avancés
• Activer les applications 32 bits true

La solution pour Windows 2008 Server x64 est la suivante:

1. Ouvrez cmd.exe avec l’autorisation de l’administrateur.
2. Copiez la DLL dans le dossier C: \ Windows \ SysWOW64
3. exécuter regsvr32 à partir de C: \ Windows \ SysWOW64
4. Vérifiez que dll est dans le registre de Windows.
5. Si vous avez un fichier .exe x86 qui utilise la DLL, l’exe doit être compilé en mode x86.
6. L’exe doit être installé dans le dossier C: \ Program Files (x86)

Cette procédure est valide, ça va.

Avait un problème connexe avec un correctif différent, mais similaire:

Un projet de service Windows a été défini sur “Any-CPU” avec une DLL 64 bits. Même message d’erreur J’ai essayé plein de choses, mais rien n’a fonctionné. Enfin, je suis entré dans le projet Properties -> Build et j’ai remarqué que le projet “Prefer 32-bit” était coché. Désélectionné ceci et plus d’erreur.

Je suppose que le service Windows attendait une DLL 32 bits et ne pouvait pas le trouver.

Je n’ai modifié aucun paramètre de compilation.

Il suffit de définir “Activer l’application 32 bits = True” dans les parameters avancés d’AppPool.

Ça a fonctionné pour moi

J’avais le même problème, mais les autres réponses ne fournissaient qu’une partie de la solution.

La solution est double:

Retirez le 64bit du registre.

• c: \ windows \ system32 \ regsvr32.exe / U
• Cela ne supprimera pas les références aux autres copies de la DLL dans d’autres dossiers.

ou

• Recherchez la clé appelée HKEY_CLASSES_ROOT \ CLSID {……} \ InprocServer32. Cette clé aura le nom de fichier de la DLL comme valeur par défaut.
• J’ai supprimé le dossier HKEY_CLASSES_ROOT \ CLSID {……}.

Enregistrez-le en 32 bits:

• C:\Windows\SysWOW64\regsvr32

L’enregistrer en tant que 32 bits sans supprimer l’enregistrement 64 bits ne résout pas mon problème.

Pour passer à x86:

1. Créez un projet d’installation pour votre solution.
2. Après l’avoir créé, accédez à l’explorateur de solutions, cliquez avec le bouton droit sur le projet d’installation.
   • Appuyez sur Configuration Manager.
   • Cliquez sur la liste déroulante “Active Solution Platform” et sélectionnez Nouveau (s’il n’y a pas de x86 affiché)
   • Sélectionnez le premier combo x86, puis appuyez sur OK.
   • reconstruire le projet d’installation, puis reconstruire tout le projet.

Si vous exécutez un site Web, vous pouvez également essayer de configurer votre pool d’applications pour désactiver les applications 32 bits (sous les parameters avancés d’un pool).

Pour quiconque utilise VSTO, le problème pour moi était une référence manquante à l’assemblage de office . Cela apparaîtrait également si vous essayiez d’instancier manuellement certains objects VSTO.

Dans mon cas personnel, le problème a été résolu en recherchant l’ID de classe dans le registre de Windows sur la machine de développement (car le problème était survenu sur un PC client). Cette action sera placée dans le composant COM à l’origine du problème: une bibliothèque x86 référencée dans mon projet .NET qui n’était pas enregistrée en tant qu’OCX / COM pour l’application d’installation ou de mise à jour.

Cordialement

Mon problème était que j’avais la mauvaise version de MS Sync FrameWork (1.0) dans mes références de projet. Après la mise à jour vers la version 2.1, l’erreur est partie et la vie est de nouveau bonne.