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

Il semble que votre service a été construit contre 'N'importe quel CPU', vous causant des erreurs sur 64 bits où vous utilisez des composants COM. Vous devez le construire pour x86.

Le site Web fonctionne probablement comme un processus 32 bits, c'est pourquoi il peut utiliser le composant. Construire votre solution contre x86 forcera votre service à s'exécuter en 32 bits.

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

J'avais besoin d'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 ont fonctionné à partir de tests unitaires dans Visual Studio mais ont échoué à partir de l'Application Web hébergée dans IIS sur la même machine avec l'erreur 80040154.

Changer le pool d'applications pour " activer 32 bits Applications " résolu le problème.

Le problème est que le processus serveur est 64 bits et que la Bibliothèque est 32 bits et qu'elle essaie de créer le composant COM dans le même processus (serveur in-proc). Soit vous recompilez le serveur et le faites 32 bits, soit vous laissez le serveur inchangé et rendez le composant COM hors processus. La façon la plus simple de rendre un serveur COM hors processus est de créer un COM+ application-Panneau de configuration- > Outils D'administration - > ComponentServices.

Si vous cherchez un moyen de faire fonctionner cela sans recompiler votre application CPU, voici une autre solution de contournement potentielle:

1. Localisez votre GUID D'objet COM sous la racine HKey_Classes_Root\Wow6432Node \ CLSID\{GUID}
2. Une fois situé, ajoutez une nouvelle valeur REG_SZ (string). Le nom doit être AppID et les données doivent être le même GUID D'objet COM que vous venez de rechercher
3. Ajoutez une nouvelle clé sous HKey_Classes_Root\Wow6432Node\AppID. La nouvelle clé doit être appelée la même que la Objet COM GUID.
4. sous la nouvelle clé que vous venez d'ajouter, 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'objet 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 les propriétés de votre projet platform target x86. Vous pouvez également configurer les options iis pour fonctionner avec x86 comme ceci

• Sélectionnez le pool D'applications
• Sélectionnez le pool utilisé par votre application
• paramètres Avancés
• Activer les applications 32 bits true

Je n'ai pas modifié les paramètres de compilation.

Il suffit de définir "activer l'Application 32 bits = True" dans les paramètres avancés AppPool.

Cela a fonctionné pour moi

La solution pour windows 2008 server x64 est:

1. Ouvrez cmd.exe avec L'autorisation de L'administrateur.
2. Copiez la dll dans le dossier C:\Windows\SysWOW64
3. Exécutez regsvr32 depuis C:\Windows\SysWOW64
4. Vérifiez que la dll est dans le registre de Windows.
5. Si vous avez un .exe x86 qui utilisent la dll, l'exe doit être compilé en mode x86.
6. l'exe doit être installé dans le dossier C:\Program fichiers (x86)

Cette procédure est valide, elle est correcte.

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

J'avais un projet de service Windows défini sur "Any-CPU" en utilisant une DLL 64 bits. Même message d'erreur. Essayé tout un tas de choses, mais rien n'a fonctionné. Enfin, je suis allé dans project Properties - > Build et j'ai remarqué que le projet avait" Prefer 32-bit " vérifié. Désactivé ce et pas plus d'erreur.

Ma conjecture est que le service windows attendait une DLL 32 bits, et ne pouvait pas le trouver.

J'ai eu le même problème, mais les autres réponses n'ont fourni qu'une partie de la solution.

La solution est double:

Supprimez le 64 bits du registre.

• c:\windows\system32\regsvr32.exe / U
• cela ne supprimera pas les références à d'autres copiés de la dll dans d'autres dossiers.

Ou

• trouvez la clé appelée HKEY_CLASSES_ROOT \ CLSID{......} \ InprocServer32. Cette clé aura le nom de fichier de la DLL comme valeur par défaut.
• je suppression de la racine HKEY_CLASSES_ROOT \ CLSID{......} dossier.

Enregistrez-le comme 32bit:

• C:\Windows\SysWOW64\regsvr32 <file.dll>

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:" Active Solution Platform " combobox et sélectionnez Nouveau (S'il n'y a pas x86 affiché)
   • Sélectionnez dans le premier combo x86 puis appuyez sur OK.
   • reconstruire le projet D'installation, puis reconstruire tout le projet.

Si vous utilisez un site Web, vous pouvez également essayer de configurer votre pool d'applications pour désactiver les Applications 32 bits (sous Paramètres avancés d'un pool).

Pour toute personne utilisant VSTO, le problème pour moi était une référence manquante à l'assemblage office. Il apparaîtrait également si vous essayiez d'instancier Certains objets VSTO manuellement.

Dans mon cas personnel, le problème a été corrigé en recherchant l'id de classe dans le Registre de Windows sur la machine de développement (car le problème a été lancé dans un PC client). Cette action sera placée dans le composant COM qui provoque le problème: une bibliothèque x86 référencée dans mon projet. net qui n'était pas enregistrée comme 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 de la version 2.1, l'erreur a disparu et la vie est bonne à nouveau.