Wie löse ich die nicht registrierte COM-Ausnahmeklasse (Ausnahme von HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))?

Wenn ich versuche, eine Instanz einer COM-Klasse zu erstellen, wird eine Ausnahme als ausgelöst

Klasse nicht registriert (Ausnahme von HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Bitte schlagen Sie vor, wie ich es lösen könnte.

Es sieht so aus, als ob das Programm oder der Prozess, den Sie initialisieren möchten, entweder nicht auf Ihrem Computer installiert ist, eine beschädigte Installation aufweist oder registriert werden muss.

Entweder installieren, reparieren (über Software) oder registrieren (über Regsvr32.exe).

Sie haben uns nicht genügend Informationen zur Verfügung gestellt, um Ihnen weiter zu helfen.

Sie müssen sicherstellen, dass alle Ihre Assemblys für die richtige Architektur kompiliert werden. Versuchen Sie, die Architektur für x86 zu ändern, wenn die Neuinstallation der COM-Komponente nicht funktioniert.

Mein Problem und die Lösung

Ich habe eine 32-Bit-DLL eines Drittanbieters, die ich auf einer 2008 R2-Maschine installiert habe, die 64-Bit ist.

Ich habe einen wcf-Dienst im .net 4.5-Framework erstellt, der die 32-Bit-Drittanbieter-DLL für den Prozess aufruft. Jetzt habe ich eine Eigenschaft erstellt, die auf "jede" CPU abzielt, und sie auf dem 64-Bit-Computer bereitgestellt.

Als ich versuchte, den wcf-Dienst aufzurufen, wurde der Fehler "80040154 Klasse nicht registriert (Ausnahme von HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG") angezeigt.

Jetzt habe ich ProcMon.exe verwendet, um das com-Registrierungsproblem zu verfolgen, und festgestellt, dass der Prozess nach dem Registrierungseintrag unter HKLM \ CLSID und HKCR \ CLSID sucht, wo es keinen Eintrag gibt.

Es wurde festgestellt, dass Microsoft die 32-Bit-COM-Komponenten nicht in den Pfaden HKLM \ CLSID, HKCR \ CLSID auf einem 64-Bit-Computer registriert, sondern den Eintrag in den Pfaden HKLM \ Wow6432Node \ CLSID und HKCR \ Wow6432Node \ CLSID platziert.

Jetzt ist der Konflikt ein 64-Bit-Prozess, der versucht, einen 32-Bit-Prozess auf einem 64-Bit-Computer aufzurufen, der nach dem Registrierungseintrag in HKLM \ CLSID, HKCR \ CLSID sucht. Die Lösung besteht darin, den 64-Bit-Prozess zu zwingen, den Registrierungseintrag unter HKLM \ Wow6432Node \ CLSID und HKCR \ Wow6432Node \ CLSID zu überprüfen.

Dies kann erreicht werden, indem die Eigenschaften des wcf-Serviceprojekts so konfiguriert werden, dass sie auf 'X86'-Computer anstatt auf' Beliebig 'abzielen.

Nach der Bereitstellung der 'X86'-Version auf dem 2008 R2-Server wurde das Problem "System.BadImageFormatException: Datei oder Assembly konnte nicht geladen werden" angezeigt.

Die Lösung für diese badimageformatexception besteht darin, die 'Enable32bitApplications' in den IIS Apppool-Eigenschaften für den richtigen Apppool auf 'True' zu setzen.

Beachten Sie auch, dass der Klassenkontext beim Initialisieren diese Ausnahme erstellen kann. Wenn Sie ein Objekt haben, das als INPROC_SERVER codiert ist, aber versuchen, CoCreateInstance als CLSCTX_LOCAL_SERVER zu verwenden, wird dieser Fehler ebenfalls angezeigt.

Sie müssen sicherstellen, dass das Objekt registriert ist und CoCreateInstance eine Instanz mit dem richtigen Klassenkontext erstellt.

Wenn Sie 64-Bit-COM-Komponenten in einer Webanwendung unter IIS verwenden, stellen Sie sicher, dass im Anwendungspool keine 32-Bit-Anwendungen zulässig sind ( 32-Bit-Anwendungen aktivieren: in erweiterten Einstellungen false ).

Ich habe es zum Laufen gebracht, indem ich 32-Bit-Anwendungen in den erweiterten Einstellungen des Anwendungspools aktiviert habe. Klicken Sie mit der rechten Maustaste auf den Anwendungspool und wählen Sie erweiterte Einstellungen - aktivieren Sie 32-Bit-Anwendungen. Dies kann jemandem da draußen helfen.

Durch Registrieren der Klasse (insbesondere ihrer CLSID) - siehe zB hier .

in meinem Fall

my platform ist x64

the Dll library(sdk)und das redistributable packageist x64

so

1. im Lösungs-Explorer navigate to your project

2. öffnen Properties

3. change the Platform target from AnyCPU to x64

Die Art und Weise, wie ich dieses Problem gelöst habe, war die Registrierung der COMVia regsvr32.

Stellen Sie sicher, dass die von Ihnen aufgerufene COM registriert ist.

Meine Anwendung wurde verwendet xceedcry.dllund ich habe sie nicht registriert. Nachdem ich es registriert hatte, funktionierte die Anwendung einwandfrei.

Meine Lösung bestand darin, " 32-Bit-Anwendungen aktivieren " in den erweiterten Einstellungen des relativen App-Pools in IIS in "True " zu ändern .

In meinem Fall wurde die Klasse ordnungsgemäß registriert und in JEDEM CPU / 64-Bit- Modus erstellt.

Die Eigenschaft 32-Bit-Anwendungen aktivieren des IIS-Anwendungspools der Anwendung, die die Klasse verwendet, wurde jedoch auf True festgelegt .

Die Klasse wurde aufgrund der Nichtübereinstimmung der Architektur zwischen der Anwendungspoolkonfiguration und der tatsächlich registrierten Klasse nicht gefunden.

Durch Festlegen von " 32-Bit-Anwendungen aktivieren" auf " Falsch" wurde das Problem behoben.

Für mich musste ich eine 64-Bit-Build-Konfiguration erstellen.

Ich hatte das gleiche Problem mit MapWinGis. Ich habe die Lösung gefunden, indem ich an Visual Studios 2015 Windows Forms Proyect gearbeitet habe. Klicken Sie einfach mit der rechten Maustaste auf Proyect-> Eigenschaften-> Erstellen, setzen Sie die Konfiguration auf Alle Konfigurationen und setzen Sie sie in der Conbobox "Plattformziel" auf x64.

Ich bin auf dieses Problem gestoßen, als ich eine .NET-Assembly von einem C ++ - Client über COM aufgerufen habe. Es stellt sich heraus, dass eine der Assemblys, von denen die .Net-Assembly abhängig war, nicht gefunden werden konnte. Ich rang eine Weile und versuchte herauszufinden, was mit der 1. Versammlung nicht stimmte, aber es war tatsächlich eine der Abhängigkeiten der 1. Versammlung. Beim Aufrufen von CoCreateInstance () vom C ++ - Client sind zwei verschiedene Fehler aufgetreten. Der erste war: REGDB_E_CLASSNOTREG Klasse nicht registriert . Der zweite Versuch war: 0x80131040: Die Manifestdefinition der gefundenen Assembly stimmt nicht mit der Assemblyreferenz überein.

Überprüfen Sie daher, ob die Referenzen Ihrer Baugruppe vorhanden sind. Ich entdeckte dies, indem ich die erste Assembly mit dotPeek durchsuchte und bemerkte, dass eine der Referenzen fehlte. Durch Platzieren der richtigen Version der Abhängigkeit in dem Ordner wurden beide Fehler behoben.

Ich habe meine Anwendung für jede CPU kompiliert und das Hauptproblem stellte sich heraus, dass der Adobe Reader älter installiert wurde. 10.x muss v11.x aktualisieren. Auf diese Weise kann ich dieses Problem beheben.

Ich bin auf dasselbe Problem mit einer COM-Klasse gestoßen, dh "Klasse nicht registrierte Ausnahme" zur Laufzeit. Für mich war ich in der Lage, eine Lösung zu finden, indem ich in die Datei app.config ging und die Elemente 'startup' und 'SupportedRuntime' in Folgendes änderte:

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0"/>
  </startup>
</configuration>

Weitere Informationen finden Sie hier http://stackoverflow.com/questions/1604663/

und hier https://msdn.microsoft.com/en-us/library/w4atty68(v=vs.110).aspx

Ich sollte beachten, dass ich Visual Studio 2017 ausführe. Ziel-CPU = x86 Interop-Typ einbetten = true (im Eigenschaftenfenster)

Gehen Sie in das Verzeichnis des .Net-Frameworks und registrieren Sie die entsprechende DLL im Regsvr32.exe- Leerraum-DLL-Pfad.

Ich habe das gleiche Problem konfrontiert. Nachdem ich einige Nachforschungen angestellt hatte, fand ich eine Lösung für mich und es kann nützlich sein. Das Problem hängt nach meiner Beobachtung nicht nur mit der Neuinstallation zusammen, sondern auch von den Zugriffsberechtigungen.

Schritt 1: Reparieren Sie das jeweilige COM-Objekt.

Schritt 2: Komponentendienste> Computer> Arbeitsplatz> DCOM-Konfiguration> Wählen Sie Ihr COM-Objekt aus> Rechtsklick> Eigenschaften> Registerkarte Sicherheit> Zugriffsberechtigungen> Wählen Sie Anpassen> Klicken Sie auf BEARBEITEN> Wählen Sie IIS_USER (falls nicht vorhanden, erstellen Sie mit vollständigen Rechten) und geben Sie vollständig an Zugriff und klicken Sie auf OK.

Zur Registerkarte Identität wechseln> Sie können "Interaktiver Benutzer" oder "Dieser Benutzer" auswählen> Klicken Sie auf Übernehmen und auf OK. Wenn Sie "Dieser Benutzer" auswählen, müssen wir diesem Server Administratorrechte gewähren

Schritt 3: Öffnen Sie IIS Manager> Starten Sie die Anwendungspools neu.

Hinweis: Starten Sie den Server bei Bedarf neu

Hier finden Sie die Lösung, führen Sie das Tool mmc -32 aus (nicht dcomcfg).

Versuchen Sie auf einem 64-Bit-System mit 32-Bit-Office Folgendes:

Start
Run
mmc -32
File
Add Remove Snap-in
Component Services
Add
OK
Console Root
Component Services
Computers
My Computer
DCOM Config
Microsoft Excel Application