Quando provo a creare un'istanza di una classe COM, viene generata un'eccezione come
Classe non registrata (eccezione da HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
Per favore suggerisci come potrei risolverlo?
Quando provo a creare un'istanza di una classe COM, viene generata un'eccezione come
Classe non registrata (eccezione da HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))
Per favore suggerisci come potrei risolverlo?
Risposte:
Sembra che qualsiasi programma o processo che stai tentando di inizializzare non sia installato sulla tua macchina, abbia un'installazione danneggiata o debba essere registrato.
Installalo, riparalo (tramite Aggiungi / Rimuovi programmi) o registralo (tramite Regsvr32.exe).
Non ci hai fornito informazioni sufficienti per aiutarti più di questo.
È necessario assicurarsi che tutti gli assembly vengano compilati per l'architettura corretta. Prova a cambiare l'architettura per x86 se la reinstallazione del componente COM non funziona.
Il mio problema e la soluzione
Ho una dll di terze parti a 32 bit che ho installato nella macchina 2008 R2 che è a 64 bit.
Ho un servizio wcf creato nel framework .net 4.5 che chiama la dll di terze parti a 32 bit per il processo. Ora ho la proprietà build impostata per targetizzare "qualsiasi" cpu e l'ho distribuita sulla macchina a 64 bit.
quando ho provato a richiamare il servizio wcf ho ricevuto l'errore "80040154 Classe non registrata (eccezione da HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"
Ora ho utilizzato ProcMon.exe per tracciare il problema del registro com e ho identificato che il processo sta cercando la voce di registro in HKLM \ CLSID e HKCR \ CLSID dove non è presente alcuna voce.
È venuto a sapere che Microsoft non registrerà i componenti com a 32 bit nei percorsi HKLM \ CLSID, HKCR \ CLSID nella macchina a 64 bit piuttosto colloca la voce nei percorsi HKLM \ Wow6432Node \ CLSID e HKCR \ Wow6432Node \ CLSID.
Ora il conflitto è un processo a 64 bit che tenta di richiamare il processo a 32 bit in una macchina a 64 bit che cercherà la voce di registro in HKLM \ CLSID, HKCR \ CLSID. La soluzione è che dobbiamo forzare il processo a 64 bit a guardare la voce di registro in HKLM \ Wow6432Node \ CLSID e HKCR \ Wow6432Node \ CLSID.
Ciò può essere ottenuto configurando le proprietà del progetto del servizio wcf in modo che si indirizzino alla macchina "X86" invece che a "Qualsiasi".
Dopo aver distribuito la versione "X86" sul server 2008 R2, è stato riscontrato il problema "System.BadImageFormatException: Impossibile caricare il file o l'assembly"
La soluzione a questa badimageformatexception è l'impostazione di "Enable32bitApplications" su "True" nelle proprietà Apppool IIS per l'apppool corretto.
Notare inoltre che il contesto della classe durante l'inizializzazione può creare quell'eccezione. Se hai un oggetto codificato come INPROC_SERVER ma provi a CoCreateInstance come CLSCTX_LOCAL_SERVER, riceverai anche quell'errore.
È necessario assicurarsi che l'oggetto sia registrato e che CoCreateInstance stia creando un'istanza con il contesto di classe corretto.
DesktopWallpaperusando CLSCTX_INPROC(invece di CLSCTX_ALL) otterrai l' 0x80040154 (REGDB_E_CLASSNOTREG)errore.
Ho funzionato abilitando le applicazioni a 32 bit nelle impostazioni avanzate del pool di applicazioni. Fare clic con il pulsante destro del mouse sul pool di applicazioni e scegliere le impostazioni avanzate - abilitare le applicazioni a 32 bit. Questo può aiutare qualcuno là fuori.
Registrando la classe (in particolare il suo CLSID) - vedere ad esempio qui .
Nel mio caso la classe è stata registrata correttamente e costruita in QUALSIASI CPU / 64 bit modalità .
Ma la proprietà Abilita applicazioni a 32 bit del pool di applicazioni IIS dell'applicazione che utilizza la classe era impostata su True .
La classe non è stata trovata a causa della mancata corrispondenza dell'architettura tra la configurazione del pool di applicazioni e la classe effettivamente registrata.
L'impostazione Abilita applicazioni a 32 bit su False ha risolto il problema.

Ho avuto lo stesso problema utilizzando MapWinGis. Ho trovato la soluzione, lavorando su visual studio 2015 windows forms proyect, basta fare clic destro sul progetto-> proprietà-> Build, impostare la configurazione su Tutte le configurazioni e nel conbobox "platform target" impostarlo a x64.
Mi sono imbattuto in questo problema chiamando un assembly .Net da un client C ++ tramite COM. Risulta che non è stato possibile trovare uno degli assembly da cui dipendeva l'assembly .Net. Ho lottato per un po 'cercando di capire cosa c'era di sbagliato nel primo assembly, ma in realtà era una delle dipendenze del primo assembly. Ho ricevuto due diversi errori durante la chiamata a CoCreateInstance () dal client C ++. Il primo era: REGDB_E_CLASSNOTREG Classe non registrata e il secondo tentativo era: 0x80131040: la definizione manifest dell'assembly individuato non corrisponde al riferimento all'assembly.
Quindi controlla che i riferimenti del tuo assembly siano presenti. L'ho scoperto sfogliando il primo assembly con dotPeek e notando che mancava uno dei suoi riferimenti. Posizionare la versione corretta della dipendenza nella cartella ha risolto entrambi gli errori.
Stavo compilando la mia applicazione mirata a qualsiasi CPU e il problema principale si è scoperto che adobe reader è stato installato il vecchio v10.x deve aggiornare v11.x , questo è il modo in cui riesco a risolvere questo problema.
Ho riscontrato lo stesso problema utilizzando una classe COM, ovvero "Eccezione di classe non registrata" in fase di esecuzione. Per me sono stato in grado di risolvere andando al file app.config e cambiare gli elementi "startup" e "supportedRuntime" in qualcosa di simile:
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
</configuration>
Puoi leggere di più sui dettagli qui http://stackoverflow.com/questions/1604663/
e qui https://msdn.microsoft.com/en-us/library/w4atty68(v=vs.110).aspx
Dovrei notare che sto eseguendo Visual Studio 2017. Target cpu = x86 Embed Interop Type = true (nella finestra delle proprietà)
vai alla directory di .Net framework e registra la rispettiva dll con il percorso dll spazio vuoto Regsvr32.exe .
Ho affrontato lo stesso problema. Dopo aver fatto qualche ricerca ho trovato la soluzione per me e potrebbe essere utile. Il problema non è solo correlato alla reinstallazione come da mia osservazione, dipende anche dalle autorizzazioni di accesso.
Passaggio 1: riparare il particolare oggetto COM.
Passaggio 2: Servizi componenti> Computer> Risorse del computer> Configurazione DCOM> Seleziona il tuo oggetto COM> Fare clic con il pulsante destro del mouse> Proprietà> scheda Protezione> Autorizzazioni di accesso> Scegli Personalizza> Fai clic su MODIFICA> Seleziona IIS_USER (se non esiste, crea con diritti completi) e dai completo accedere e fare clic su OK.
Passare alla scheda Identità> È possibile selezionare "Utente interattivo" o "Questo utente"> Fare clic su Applica e OK. Se scegli "Questo utente", dobbiamo fornire l'utente con privilegi di amministratore a quel server
Passaggio 3: aprire Gestione IIS> Riavvia i pool di applicazioni.
Nota: se necessario, riavviare il server
Qui trova la soluzione, esegui lo strumento mmc -32 (non dcomcfg)
Su un sistema a 64 bit con Office a 32 bit, prova questo:
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
