Jak rozwiązać niezarejestrowaną klasę wyjątku COM (wyjątek od HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))?

Kiedy próbuję utworzyć wystąpienie klasy COM, zgłasza wyjątek jako

Klasa niezarejestrowana (wyjątek od HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Proszę zasugerować, jak mogę to rozwiązać?

Wygląda na to, że którykolwiek program lub proces, który próbujesz zainicjować, nie jest zainstalowany na Twoim komputerze, ma uszkodzoną instalację lub musi zostać zarejestrowany.

Zainstaluj go, napraw (za pomocą Dodaj / usuń programy) lub zarejestruj (za pomocą programu Regsvr32.exe).

Nie dostarczyłeś wystarczająco dużo informacji, abyśmy mogli Ci pomóc.

Musisz upewnić się, że wszystkie zestawy są kompilowane pod kątem poprawnej architektury. Spróbuj zmienić architekturę dla x86, jeśli ponowna instalacja składnika COM nie działa.

Mój problem i rozwiązanie

Mam 32-bitową bibliotekę DLL innej firmy, którą zainstalowałem na maszynie 2008 R2, która jest 64-bitowa.

Mam usługę wcf utworzoną w ramach .NET 4.5, która wywołuje 32-bitową bibliotekę DLL innej firmy dla procesu. Teraz mam właściwość budowania ustawioną na docelowy „dowolny” procesor i wdrożyłem ją na komputerze 64-bitowym.

gdy próbowałem wywołać usługę wcf, wystąpił błąd „80040154 Niezarejestrowana klasa (wyjątek od HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG”)

Teraz użyłem ProcMon.exe do prześledzenia problemu z rejestrem com i stwierdziłem, że proces szuka wpisu rejestru w HKLM \ CLSID i HKCR \ CLSID, gdzie nie ma wpisu.

Dowiedziałem się, że Microsoft nie zarejestruje 32-bitowych komponentów com w ścieżkach HKLM \ CLSID, HKCR \ CLSID na komputerze 64-bitowym, ale umieści wpis w ścieżkach HKLM \ Wow6432Node \ CLSID i HKCR \ Wow6432Node \ CLSID.

Teraz konflikt jest procesem 64-bitowym próbującym wywołać proces 32-bitowy na komputerze 64-bitowym, który będzie szukał wpisu rejestru w HKLM \ CLSID, HKCR \ CLSID. Rozwiązanie polega na tym, że musimy zmusić proces 64-bitowy, aby spojrzał na wpis rejestru w HKLM \ Wow6432Node \ CLSID i HKCR \ Wow6432Node \ CLSID.

Można to osiągnąć, konfigurując właściwości projektu usługi wcf tak, aby były kierowane na maszynę „X86” zamiast „Any”.

Po wdrożeniu wersji „X86” na serwerze 2008 R2 pojawił się problem „System.BadImageFormatException: Could not load file or assembly”

Rozwiązaniem tego badimageformatexception jest ustawienie „Enable32bitApplications” na „True” we właściwościach IIS Apppool dla odpowiedniej puli aplikacji.

Należy również zauważyć, że kontekst klasy podczas inicjowania może utworzyć ten wyjątek. Jeśli masz obiekt, który jest zakodowany jako INPROC_SERVER, ale spróbujesz CoCreateInstance jako CLSCTX_LOCAL_SERVER, również otrzymasz ten błąd.

Musisz upewnić się, że obiekt jest zarejestrowany, a CoCreateInstance tworzy instancję z odpowiednim kontekstem klasy.

Jeśli używasz 64-bitowych składników COM w aplikacji sieci Web w usługach IIS, upewnij się, że pula aplikacji nie zezwala na aplikacje 32-bitowe ( Włącz aplikacje 32-bitowe: fałsz w ustawieniach zaawansowanych)

Uruchomiłem go, włączając aplikacje 32-bitowe w ustawieniach zaawansowanych puli aplikacji. Kliknij prawym przyciskiem myszy pulę aplikacji i wybierz ustawienia zaawansowane - włącz aplikacje 32-bitowe. To może komuś pomóc.

Rejestrując klasę (a konkretnie jej CLSID) - zobacz np . Tutaj .

w moim przypadku

my platform to x64

the Dll library(sdk)a redistributable packagejest x64

więc

1. w eksploratorze rozwiązań navigate to your project

2. otwarty Properties

3. change the Platform target from AnyCPU to x64

Sposób, w jaki rozwiązałem ten problem, polegał na zarejestrowaniu domeny COMvia regsvr32.

upewnij się, że wywoływany model COM jest zarejestrowany.

Moja aplikacja korzystała, xceedcry.dlla ja jej nie rejestrowałem. Po zarejestrowaniu aplikacja działała dobrze.

Moim rozwiązaniem była zmiana opcji „ Włącz aplikacje 32-bitowe ” na True w ustawieniach zaawansowanych odpowiedniej puli aplikacji w usługach IIS.

W moim przypadku klasa została poprawnie zarejestrowana i zbudowana w DOWOLNYM trybie CPU / 64-bitowym .

Ale Enable 32-bitowych aplikacji własność puli aplikacji IIS z aplikacji, która używa klasy została ustawiona na wartość True .

Nie znaleziono klasy z powodu niezgodności architektury między konfiguracją puli aplikacji a rzeczywistą zarejestrowaną klasą.

Ustawienie opcji Włącz aplikacje 32-bitowe na Fałsz rozwiązało problem.

Dla mnie musiałem stworzyć konfigurację 64-bitową.

Miałem ten sam problem, używając MapWinGis. Znalazłem rozwiązanie, pracując nad projektami formularzy Windows Visual Studio 2015, po prostu kliknij prawym przyciskiem myszy na proyect-> properties-> Build, ustaw konfigurację na Wszystkie konfiguracje, a w „platformie target” conbobox ustaw ją na x64.

Napotkałem ten problem, wywołując zestaw .Net z klienta C ++ przez COM. Okazuje się, że nie można znaleźć jednego z zestawów, od których zależał zestaw .Net. Przez chwilę walczyłem, próbując dowiedzieć się, co jest nie tak z pierwszym montażem, ale w rzeczywistości była to jedna z zależności pierwszego zgromadzenia. Otrzymałem dwa różne błędy podczas wywoływania CoCreateInstance () z klienta C ++. Pierwsza to: REGDB_E_CLASSNOTREG Klasa niezarejestrowana, a druga próba: 0x80131040: definicja manifestu zlokalizowanego zestawu nie jest zgodna z odwołaniem do zestawu.

Sprawdź więc, czy istnieją odwołania do zestawu. Odkryłem to, przeglądając pierwszy zestaw za pomocą dotPeek i zauważając, że brakuje jednego z jego odniesień. Umieszczenie poprawnej wersji zależności w folderze rozwiązało oba błędy.

Kompilowałem swoją aplikację pod kątem dowolnego procesora i głównym problemem okazało się, że zainstalowano program Adobe Reader, starsza wersja 10.x wymaga aktualizacji wersji 11.x , w ten sposób mogę rozwiązać ten problem.

Napotkałem ten sam problem, używając klasy COM, tj. „Wyjątek niezarejestrowany w klasie” w czasie wykonywania. Dla mnie udało mi się rozwiązać, przechodząc do pliku app.config i zmieniając elementy „startup” i „supportedRuntime” na coś takiego:

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

Możesz przeczytać więcej o szczegółach tutaj http://stackoverflow.com/questions/1604663/

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

Powinienem zauważyć, że używam Visual Studio 2017. Docelowy procesor = x86 Embed Interop Type = true (w oknie właściwości)

przejdź do katalogu platformy .Net i zarejestruj odpowiednią bibliotekę dll za pomocą ścieżki dll białej przestrzeni Regsvr32.exe .

Zmierzyłem się z tym samym problemem. Po przeprowadzeniu pewnych badań znalazłem dla mnie poprawkę i może to być przydatne. Z moich obserwacji problem dotyczy nie tylko ponownej instalacji, zależy również od uprawnień dostępu.

Krok 1: Napraw konkretny obiekt COM.

Krok 2: Usługi składowe> Komputery> Mój komputer> Konfiguracja DCOM> Wybierz obiekt COM> kliknij prawym przyciskiem myszy> Właściwości> karta Zabezpieczenia> Uprawnienia dostępu> Wybierz Dostosuj> Kliknij EDYTUJ> Wybierz IIS_USER (jeśli nie istnieje, utwórz z pełnymi uprawnieniami) i podaj pełne dostęp i kliknij OK.

Przejdź do karty Tożsamość> Możesz wybrać „Użytkownik interaktywny” lub „Ten użytkownik”> Kliknij Zastosuj i OK. Jeśli wybierzesz „Ten użytkownik”, musimy nadać temu serwerowi uprawnienia administratora

Krok 3: Otwórz Menedżera usług IIS> Uruchom ponownie pule aplikacji.

Uwaga: W razie potrzeby zrestartuj serwer

Tutaj znajdź rozwiązanie, uruchom narzędzie mmc -32 (nie dcomcfg)

W 64-bitowym systemie z 32-bitowym pakietem Office spróbuj tego:

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