Como resolver a classe de exceção COM não registrada (exceção de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))?

Quando tento criar uma instância de uma classe COM, ele lança uma exceção como

Classe não registrada (exceção de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG))

Por favor, sugira como eu poderia resolver isso?

Parece que qualquer programa ou processo que você está tentando inicializar não está instalado em sua máquina, tem uma instalação danificada ou precisa ser registrado.

Instale-o, repare-o (por meio de Adicionar / Remover Programas) ou registre-o (via Regsvr32.exe).

Você não forneceu informações suficientes para ajudá-lo mais do que isso.

Você precisa ter certeza de que todos os seus assemblies estão compilando para a arquitetura correta. Tente mudar a arquitetura para x86 se reinstalar o componente COM não funcionar.

Meu problema e a solução

Eu tenho uma dll de terceiros de 32 bits que instalei na máquina 2008 R2, que é de 64 bits.

Eu tenho um serviço wcf criado na estrutura .net 4.5 que chama a dll de terceiros de 32 bits para o processo. Agora eu tenho a propriedade de construção definida para ter como alvo 'qualquer' cpu e implantei na máquina de 64 bits.

quando tentei invocar o serviço wcf, obtive o erro "80040154 Classe não registrada (exceção de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"

Agora eu usei ProcMon.exe para rastrear o problema de registro COM e identifiquei que o processo está procurando a entrada do registro em HKLM \ CLSID e HKCR \ CLSID onde não há entrada.

Soube que a Microsoft não registrará os componentes de comunicação de 32 bits nos caminhos HKLM \ CLSID, HKCR \ CLSID na máquina de 64 bits, em vez de colocar a entrada nos caminhos HKLM \ Wow6432Node \ CLSID e HKCR \ Wow6432Node \ CLSID.

Agora, o conflito é um processo de 64 bits tentando invocar o processo de 32 bits na máquina de 64 bits que procurará a entrada do registro em HKLM \ CLSID, HKCR \ CLSID. A solução é forçar o processo de 64 bits a examinar a entrada do registro em HKLM \ Wow6432Node \ CLSID e HKCR \ Wow6432Node \ CLSID.

Isso pode ser alcançado configurando as propriedades do projeto de serviço wcf para direcionar para a máquina 'X86' em vez de 'Qualquer'.

Depois de implantar a versão 'X86' no servidor 2008 R2, surgiu o problema "System.BadImageFormatException: não foi possível carregar o arquivo ou montagem"

A solução para este badimageformatexception é definir 'Enable32bitApplications' como 'True' nas propriedades de Apppool do IIS para o apppool certo.

Observe também que o contexto da classe ao inicializar pode criar essa exceção. Se você tiver um objeto codificado como INPROC_SERVER, mas tentar CoCreateInstance como CLSCTX_LOCAL_SERVER, também obterá esse erro.

Você precisa se certificar de que o objeto está registrado e o CoCreateInstance está criando uma instância com o contexto de classe correto.

Se você estiver usando componentes COM de 64 bits em um aplicativo da web no IIS, certifique-se de que o pool de aplicativos esteja definido para não permitir aplicativos de 32 bits ( Habilitar aplicativos de 32 bits: falso nas configurações avançadas)

Comecei a trabalhar habilitando aplicativos de 32 bits nas configurações avançadas do pool de aplicativos. Clique com o botão direito do mouse no pool de aplicativos e escolha as configurações avançadas - habilitar aplicativos de 32 bits. Isso pode ajudar alguém lá fora.

Ao registrar a classe (especificamente seu CLSID) - veja, por exemplo, aqui .

No meu caso

my platform é x64

the Dll library(sdk)e o redistributable packageé x64

tão

1. no explorador de soluções navigate to your project

2. abrir Properties

3. change the Platform target from AnyCPU to x64

A maneira que resolvi esse problema foi cadastrando o COMvia regsvr32.

certifique-se de que o COM que você está chamando esteja registrado.

Meu aplicativo estava usando xceedcry.dlle eu não estava registrando. Depois de registrá-lo, o aplicativo funcionou bem.

Minha solução foi alterar " Habilitar aplicativos de 32 bits " para Verdadeiro nas configurações avançadas do pool de aplicativos relativo no IIS.

No meu caso, a classe foi registrada corretamente e construída em QUALQUER CPU / modo de 64 bits .

Mas a propriedade Habilitar aplicativos de 32 bits do pool de aplicativos IIS do aplicativo que usa a classe foi definida como True .

A classe não foi encontrada devido à incompatibilidade de arquitetura entre a configuração do pool de aplicativos e a classe registrada real.

Definir Ativar aplicativos de 32 bits como Falso corrigiu o problema.

Para mim, tive que criar uma configuração de compilação de 64 bits.

Eu tive o mesmo problema ao usar o MapWinGis. Eu encontrei a solução, trabalhando no projeto do Windows Forms do Visual Studio 2015, basta clicar com o botão direito do mouse no projeto-> Propriedades-> Build, definir a configuração para Todas as configurações e no conbobox "plataforma alvo" definir para x64.

Corri para este problema ao chamar um assembly .Net de um cliente C ++ via COM. Acontece que um dos assemblies do qual o assembly .Net dependia não foi encontrado. Lutei um pouco tentando descobrir o que havia de errado com a 1ª montagem, mas na verdade era uma das dependências da 1ª montagem. Recebi dois erros diferentes ao chamar CoCreateInstance () do cliente C ++. A primeira foi: REGDB_E_CLASSNOTREG Classe não registrada E a segunda tentativa foi: 0x80131040: A definição de manifesto do assembly localizado não corresponde à referência do assembly.

Portanto, verifique se as referências de sua montagem estão presentes. Eu descobri isso navegando na primeira montagem com dotPeek e percebendo que faltava uma de suas referências. Colocar a versão correta da dependência na pasta resolveu os dois erros.

Eu estava compilando meu aplicativo visando qualquer CPU e o problema principal descobriu que o adobe reader foi instalado mais antigo v10.x precisa atualizar v11.x , esta é a maneira como eu consigo resolver esse problema.

Encontrei o mesmo problema ao usar uma classe COM, ou seja, 'Classe não registrada exceção' em tempo de execução. Para mim, consegui resolver acessando o arquivo app.config e alterando os elementos 'startup' e 'supportedRuntime' para algo como:

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

Você pode ler mais sobre os detalhes aqui http://stackoverflow.com/questions/1604663/

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

Devo observar que estou executando o Visual Studio 2017. Target cpu = x86 Embed Interop Type = true (na janela de propriedades)

vá para o diretório do .Net framework e registre sua respectiva dll com o caminho de dll de espaço em branco Regsvr32.exe .

Eu enfrentei o mesmo problema. Depois de fazer algumas pesquisas, encontrei uma solução para mim e pode ser útil. O problema não está apenas relacionado com a reinstalação, pelo que vi, depende também das permissões de acesso.

Etapa 1: Repare o objeto COM específico.

Etapa 2: Serviços de componentes> Computadores> Meu computador> Configuração DCOM> Selecione seu objeto COM> Clique com o botão direito> Propriedades> guia Segurança> Permissões de acesso> Escolha Personalizar> Clique em EDITAR> Selecione IIS_USER (se não existir, crie com direitos completos) e forneça completo acesse e clique em OK.

Mover para a guia Identidade> Você pode selecionar "Usuário interativo" ou "Este usuário"> Clique em Aplicar e OK. Se você escolher "Este usuário", temos que fornecer um usuário administrativo com privilégios para esse servidor

Etapa 3: Abra o Gerenciador do IIS> Reinicie os pools de aplicativos.

Nota: Se necessário, reinicie o servidor

Encontre aqui a solução, execute a ferramenta mmc -32 (não dcomcfg)

Em sistemas de 64 bits com Office de 32 bits, tente o seguinte:

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