Hay dos preguntas: 1. ¿Instaló / registró el componente COM en la máquina con Windows 7 x64? 2. ¿Cuál es la plataforma de destino de su aplicación, creo que debería configurar la plataforma en x86, por favor no la configure como "Cualquier CPU"? Primero registre el COM y luego ejecútelo para probar la aplicación, consulte el documento: support.microsoft.com/kb/146219 y Explicación del uso de Regsvr32 y mensajes de error
Creo que se refería a RegSvr32.exe (en oposición a RegSrv32.exe).
windowsgm
60
Debe asegurarse de que todos sus ensamblados se compilen para la arquitectura correcta. Intente cambiar la arquitectura para x86 si reinstalar el componente COM no funciona.
Esto resolvió mi proceso al no encontrar el cliente NAV 2009 R2 (ClassID 50000004-0000-1000-0001-0000836BD2D2).
Vincent Vancalbergh
14
Mi problema y la solucion
Tengo un dll de terceros de 32 bits que instalé en la máquina 2008 R2, que es de 64 bits.
Tengo un servicio wcf creado en .net 4.5 framework que llama a la dll de terceros de 32 bits para el proceso. Ahora tengo la propiedad de compilación configurada para apuntar a 'cualquier' CPU y la implementé en la máquina de 64 bits.
cuando intenté invocar el servicio wcf obtuve el error "80040154 Clase no registrada (Excepción de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"
Ahora utilicé ProcMon.exe para rastrear el problema del registro com e identifiqué que el proceso está buscando la entrada del registro en HKLM \ CLSID y HKCR \ CLSID donde no hay ninguna entrada.
Me enteré de que Microsoft no registrará los componentes com de 32 bits en las rutas HKLM \ CLSID, HKCR \ CLSID en una máquina de 64 bits, sino que coloca la entrada en las rutas HKLM \ Wow6432Node \ CLSID y HKCR \ Wow6432Node \ CLSID.
Ahora el conflicto es un proceso de 64 bits que intenta invocar un proceso de 32 bits en una máquina de 64 bits que buscará la entrada de registro en HKLM \ CLSID, HKCR \ CLSID. La solución es que tenemos que forzar el proceso de 64 bits para que mire la entrada del registro en HKLM \ Wow6432Node \ CLSID y HKCR \ Wow6432Node \ CLSID.
Esto se puede lograr configurando las propiedades del proyecto de servicio de wcf para apuntar a la máquina 'X86' en lugar de 'Cualquiera'.
Después de implementar la versión 'X86' en el servidor 2008 R2, apareció el problema "System.BadImageFormatException: No se pudo cargar el archivo o ensamblado"
La solución a esta excepción de formato de imagen incorrecta es configurar 'Enable32bitApplications' en 'True' en las propiedades de IIS Apppool para el grupo de aplicaciones correcto.
No publique respuestas idénticas a varias preguntas. Publique una buena respuesta, luego vote / marque para cerrar las otras preguntas como duplicadas. Si la pregunta no es un duplicado, adapte sus respuestas a la pregunta .
Cleopatra
10
También tenga en cuenta que el contexto de la clase al inicializar puede crear esa excepción. Si tiene un objeto codificado como INPROC_SERVER pero intenta CoCreateInstance como CLSCTX_LOCAL_SERVER, también obtendrá ese error.
Debe asegurarse de que el objeto esté registrado y que CoCreateInstance esté creando una instancia con el contexto de clase correcto.
Sí, si, por ejemplo, intenta crear DesktopWallpaperusando CLSCTX_INPROC(en lugar de CLSCTX_ALL), obtendrá el 0x80040154 (REGDB_E_CLASSNOTREG)error.
user362515
9
Si está utilizando componentes COM de 64 bits en una aplicación web en IIS, asegúrese de que el grupo de aplicaciones esté configurado para no permitir aplicaciones de 32 bits ( Habilitar aplicaciones de 32 bits: falso en la configuración avanzada)
Lo hice funcionar habilitando aplicaciones de 32 bits en la configuración avanzada del grupo de aplicaciones. Haga clic con el botón derecho en el grupo de aplicaciones y elija la configuración avanzada: habilite las aplicaciones de 32 bits. Esto puede ayudar a alguien.
Lo mismo para mi. Un dll de 32 bits utilizado en una máquina de desarrollo de 64 bits, una prueba de 64 bits y un servidor en vivo de 64 bits. Funcionó bien en la caja de desarrollo. Cuando se implementó en los servidores de prueba y en vivo, falló hasta que se permitieron aplicaciones de 32 bits en los respectivos grupos de aplicaciones de IIS y se reiniciaron los grupos. También tuve que desactivar "Incrustar tipos de interoperabilidad" (una configuración de la dll ofensiva en VS) y establecer "Copiar local" = verdadero para asegurarme de que la dll se haya copiado en su forma original en los servidores.
cymorg
3
Al registrar la clase (específicamente su CLSID), consulte, por ejemplo, aquí .
Tuve el mismo problema al usar MapWinGis. Encontré la solución, trabajando en el proyecto de formularios Windows Forms de Visual Studio 2015, simplemente haga clic derecho en el proyecto-> Propiedades-> Construir, establezca la configuración en Todas las configuraciones y en el cuadro de diálogo "Platform Target" configúrelo en x64.
Me encontré con este problema llamando a un ensamblado .Net desde un cliente C ++ a través de COM. Resulta que uno de los conjuntos de los que dependía el conjunto .Net no se pudo encontrar. Luché por un tiempo tratando de averiguar qué estaba mal con el primer ensamblaje, pero en realidad era una de las dependencias del primer ensamblado. Recibí dos errores diferentes al llamar a CoCreateInstance () desde el cliente C ++. El primero fue:
REGDB_E_CLASSNOTREG Clase no registrada
Y el segundo intento fue:
0x80131040: La definición del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado.
Así que verifique que las referencias de su ensamblaje estén presentes. Descubrí esto navegando por el primer ensamblado con dotPeek y notando que faltaba una de sus referencias. Colocar la versión correcta de la dependencia en la carpeta resolvió ambos errores.
Estaba compilando mi aplicación dirigida a cualquier CPU y el problema principal resultó que adobe reader se instaló una versión anterior de 10.x necesita actualizar v11.x , esta es la forma en que puedo resolver este problema.
Me encontré con el mismo problema al usar una clase COM, es decir, 'Excepción de clase no registrada' en tiempo de ejecución. Para mí, pude resolver yendo al archivo app.config y cambiando los elementos 'inicio' y 'supportedRuntime' a algo como:
Me he enfrentado al mismo problema. Después de investigar un poco, encontré una solución para mí y puede ser útil. El problema no solo está relacionado con la reinstalación, según mi observación, también depende de los permisos de acceso.
Paso 1: repare el objeto COM particular.
Paso 2: Servicios de componentes> Computadoras> Mi PC> Configuración DCOM> Seleccione su objeto COM> Haga clic con el botón derecho> Propiedades> pestaña Seguridad> Permisos de acceso> Elija Personalizar> Haga clic en EDITAR> Seleccione IIS_USER (si no existe, cree con derechos completos) y proporcione información completa acceder y haga clic en Aceptar.
Vaya a la pestaña Identidad> Puede seleccionar "Usuario interactivo" o "Este usuario"> Haga clic en Aplicar y Aceptar. Si elige "Este usuario", debemos otorgar un usuario privilegiado administrativo a ese servidor.
Paso 3: Abra el Administrador de IIS> Reinicie los grupos de aplicaciones.
Respuestas:
Parece que el programa o proceso que está intentando inicializar no está instalado en su máquina, tiene una instalación dañada o debe registrarse.
Puede instalarlo, repararlo (mediante Agregar o quitar programas) o registrarlo (mediante Regsvr32.exe).
No ha proporcionado suficiente información para que podamos ayudarlo más que esto.
fuente
Debe asegurarse de que todos sus ensamblados se compilen para la arquitectura correcta. Intente cambiar la arquitectura para x86 si reinstalar el componente COM no funciona.
fuente
Mi problema y la solucion
Tengo un dll de terceros de 32 bits que instalé en la máquina 2008 R2, que es de 64 bits.
Tengo un servicio wcf creado en .net 4.5 framework que llama a la dll de terceros de 32 bits para el proceso. Ahora tengo la propiedad de compilación configurada para apuntar a 'cualquier' CPU y la implementé en la máquina de 64 bits.
cuando intenté invocar el servicio wcf obtuve el error "80040154 Clase no registrada (Excepción de HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG"
Ahora utilicé ProcMon.exe para rastrear el problema del registro com e identifiqué que el proceso está buscando la entrada del registro en HKLM \ CLSID y HKCR \ CLSID donde no hay ninguna entrada.
Me enteré de que Microsoft no registrará los componentes com de 32 bits en las rutas HKLM \ CLSID, HKCR \ CLSID en una máquina de 64 bits, sino que coloca la entrada en las rutas HKLM \ Wow6432Node \ CLSID y HKCR \ Wow6432Node \ CLSID.
Ahora el conflicto es un proceso de 64 bits que intenta invocar un proceso de 32 bits en una máquina de 64 bits que buscará la entrada de registro en HKLM \ CLSID, HKCR \ CLSID. La solución es que tenemos que forzar el proceso de 64 bits para que mire la entrada del registro en HKLM \ Wow6432Node \ CLSID y HKCR \ Wow6432Node \ CLSID.
Esto se puede lograr configurando las propiedades del proyecto de servicio de wcf para apuntar a la máquina 'X86' en lugar de 'Cualquiera'.
Después de implementar la versión 'X86' en el servidor 2008 R2, apareció el problema "System.BadImageFormatException: No se pudo cargar el archivo o ensamblado"
La solución a esta excepción de formato de imagen incorrecta es configurar 'Enable32bitApplications' en 'True' en las propiedades de IIS Apppool para el grupo de aplicaciones correcto.
fuente
También tenga en cuenta que el contexto de la clase al inicializar puede crear esa excepción. Si tiene un objeto codificado como INPROC_SERVER pero intenta CoCreateInstance como CLSCTX_LOCAL_SERVER, también obtendrá ese error.
Debe asegurarse de que el objeto esté registrado y que CoCreateInstance esté creando una instancia con el contexto de clase correcto.
fuente
DesktopWallpaperusandoCLSCTX_INPROC(en lugar deCLSCTX_ALL), obtendrá el0x80040154 (REGDB_E_CLASSNOTREG)error.Si está utilizando componentes COM de 64 bits en una aplicación web en IIS, asegúrese de que el grupo de aplicaciones esté configurado para no permitir aplicaciones de 32 bits ( Habilitar aplicaciones de 32 bits: falso en la configuración avanzada)
fuente
Lo hice funcionar habilitando aplicaciones de 32 bits en la configuración avanzada del grupo de aplicaciones. Haga clic con el botón derecho en el grupo de aplicaciones y elija la configuración avanzada: habilite las aplicaciones de 32 bits. Esto puede ayudar a alguien.
fuente
Al registrar la clase (específicamente su CLSID), consulte, por ejemplo, aquí .
fuente
en mi caso
my platformes x64the Dll library(sdk)y elredistributable packagees x64entonces
en el explorador de soluciones
navigate to your projectabierto
Propertieschange the Platform target from AnyCPU to x64fuente
La forma en que resolví este problema fue registrar la
COMvíaregsvr32.asegúrese de que el COM que está invocando esté registrado.
Mi aplicación estaba usando
xceedcry.dlly no la estaba registrando. Una vez que lo registré, la aplicación funcionó bien.fuente
Mi solución fue cambiar " Habilitar aplicaciones de 32 bits " a Verdadero en la configuración avanzada del grupo de aplicaciones relativas en IIS.
fuente
En mi caso, la clase se registró correctamente y se construyó en CUALQUIER CPU / modo de 64 bits .
Pero la propiedad Habilitar aplicaciones de 32 bits del grupo de aplicaciones IIS de la aplicación que usa la clase se estableció en Verdadero .
No se encontró la clase debido a la discrepancia de arquitectura entre la configuración del grupo de aplicaciones y la clase registrada real.
Establecer Habilitar aplicaciones de 32 bits en Falso solucionó el problema.
fuente
Para mí, tuve que crear una configuración de compilación de 64 bits.
fuente
Tuve el mismo problema al usar MapWinGis. Encontré la solución, trabajando en el proyecto de formularios Windows Forms de Visual Studio 2015, simplemente haga clic derecho en el proyecto-> Propiedades-> Construir, establezca la configuración en Todas las configuraciones y en el cuadro de diálogo "Platform Target" configúrelo en x64.
fuente
Me encontré con este problema llamando a un ensamblado .Net desde un cliente C ++ a través de COM. Resulta que uno de los conjuntos de los que dependía el conjunto .Net no se pudo encontrar. Luché por un tiempo tratando de averiguar qué estaba mal con el primer ensamblaje, pero en realidad era una de las dependencias del primer ensamblado. Recibí dos errores diferentes al llamar a CoCreateInstance () desde el cliente C ++. El primero fue: REGDB_E_CLASSNOTREG Clase no registrada Y el segundo intento fue: 0x80131040: La definición del manifiesto del ensamblado ubicado no coincide con la referencia del ensamblado.
Así que verifique que las referencias de su ensamblaje estén presentes. Descubrí esto navegando por el primer ensamblado con dotPeek y notando que faltaba una de sus referencias. Colocar la versión correcta de la dependencia en la carpeta resolvió ambos errores.
fuente
Estaba compilando mi aplicación dirigida a cualquier CPU y el problema principal resultó que adobe reader se instaló una versión anterior de 10.x necesita actualizar v11.x , esta es la forma en que puedo resolver este problema.
fuente
Me encontré con el mismo problema al usar una clase COM, es decir, 'Excepción de clase no registrada' en tiempo de ejecución. Para mí, pude resolver yendo al archivo app.config y cambiando los elementos 'inicio' y 'supportedRuntime' a algo como:
<configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0"/> </startup> </configuration>Puede leer más sobre los detalles aquí http://stackoverflow.com/questions/1604663/
y aquí https://msdn.microsoft.com/en-us/library/w4atty68(v=vs.110).aspx
Debo tener en cuenta que estoy ejecutando Visual Studio 2017. Target cpu = x86 Embed Interop Type = true (en la ventana de propiedades)
fuente
Vaya al directorio de .Net framework y registre su respectivo dll con la ruta de acceso al dll de espacio en blanco Regsvr32.exe .
fuente
Me he enfrentado al mismo problema. Después de investigar un poco, encontré una solución para mí y puede ser útil. El problema no solo está relacionado con la reinstalación, según mi observación, también depende de los permisos de acceso.
Paso 1: repare el objeto COM particular.
Paso 2: Servicios de componentes> Computadoras> Mi PC> Configuración DCOM> Seleccione su objeto COM> Haga clic con el botón derecho> Propiedades> pestaña Seguridad> Permisos de acceso> Elija Personalizar> Haga clic en EDITAR> Seleccione IIS_USER (si no existe, cree con derechos completos) y proporcione información completa acceder y haga clic en Aceptar.
Vaya a la pestaña Identidad> Puede seleccionar "Usuario interactivo" o "Este usuario"> Haga clic en Aplicar y Aceptar. Si elige "Este usuario", debemos otorgar un usuario privilegiado administrativo a ese servidor.
Paso 3: Abra el Administrador de IIS> Reinicie los grupos de aplicaciones.
Nota: Si es necesario, reinicie el servidor.
fuente
Aquí encuentre la solución, ejecute la herramienta mmc -32 (no dcomcfg)
En un sistema de 64 bits con Office de 32 bits, intente esto:
Start Run mmc -32 File Add Remove Snap-in Component Services Add OK Console Root Component Services Computers My Computer DCOM Config Microsoft Excel Applicationfuente