Excel .NET COM - Error de automatización. El sistema no puede encontrar el archivo especificado

Question

Tengo un objeto COM .NET 2.0 que VBA usa en Excel. Funciona bien en mi máquina de desarrollo, pero cuando trato de usarlo en una estación de trabajo limpia de VM obtengo este error:

Error de automatización. El sistema no puede encontrar el archivo especificado.

El dll está registrado en "regasm/tlb/codebase mycom.dll" y no se ha incluido en el GAC. No tengo derechos de administración en el cuadro VM

¿Alguna idea?

Answer 1

Necesita invocar regasm con la ruta completa al ensamblado como el valor del parámetro codebase o colocar el ensamblado en una ubicación que siempre esté en la ruta para buscar bibliotecas. De lo contrario, no se encontrará cuando el cliente intente crear una instancia del objeto COM.

Answer 2

En windows 7, 64 bit y .NET 4.0 framework dll (32 bit) que quiero que se pueda usar como objeto COM para una aplicación VBA de Microsoft Excel 2010, esto es lo que funcionó para mí.

1. Copia el archivo DLL en c: (../TLB :.) \ windows \ syswow64

2. En una cáscara de cmd, ejecute

   C:\Windows\Microsoft.NET\Framework\v4.0.<whatever you have>\regasm.exe c:\windows\syswow64\<name of dll> /codebase /tlb:c:\windows\syswow64\<name of dll minus '.dll'>.tlb 
   

Puede omitir la última parte si no quiere o no necesita intellisense en la máquina, está registrando el ensamblaje.

La clave que tuve fue que en XP nunca tuve que usar el parámetro/codebase antes, pero esa era la clave necesaria antes de que esto funcionara.

Answer 3

Recibí este error "Error de automatización. El sistema no puede encontrar el archivo especificado" después de haber creado .NET .dll (v4.0) .NET con la intención de usarlo en una aplicación VB6 (decoré mi clase con " ClassInterface "y" ComVisible "atributos, métodos con" ComVisible ").

Ejecuto "regasm.exe -tlb C: \ PathTo \ MyDll.dll" pero recibí el error anterior después de agregar el archivo .tlb como referencia en mi aplicación VB6 y ejecutarlo/depurarlo. Solo después de agregar el parámetro "-codebase" a la llamada regasm.exe y volver a agregar la referencia .tlb, se resolvió el error.

Pensé que compartiría mi experiencia.

Answer 4

También recibo un error de automatización. Mi referencia (en MS Access) fue a un archivo TLB. El archivo DLL correspondiente faltaba en la carpeta que contenía el archivo TLB y esto provocó que apareciera el mensaje 'error de automatización'. Agregar la DLL de nuevo en arreglado.

Answer 5

Me estaba dando el mismo error (no podía consumir el objeto .NET del bacalao VB6 heredado en una segunda máquina dev, después de que estaba trabajando en una primera máquina donde originalmente lo escribí). La DLL de .NET compilada y registrada correctamente - Intenté todo tipo de combinaciones - con y sin utilizar la configuración de compilación "Registrar para Interoperabilidad COM" en VS; registro manual a través de regasm.exe y probar esto con y sin el parámetro/codebase; intenté habilitar y suprimir el atributo de nivel de ensamblaje COM Visible (al suprimir, configuré el atributo en la clase que necesito consumir desde COM). Pero nada funcionó, seguí recibiendo el mismo error.

Resulta que actualicé la salida de DLL a .NET 4.5 en la segunda máquina, mientras que originalmente estaba construyendo un ensamblado .NET 2.0. Mi proyecto tenía algunas referencias dirigidas a DLL Interop de terceros que ejecutaban .NET 2.0. Cuando actualicé estas referencias y reconstruí el archivo DLL -o bien- configuré mi proyecto para que se ejecutara en .NET 2.0, mi problema fue resuelto. Cuando uso/codebase (que VS hace automáticamente) encontré que no necesitaba poner mi DLL en el directorio de la aplicación o en \ syswow64. Además, los documentos de MSDN indican que debe usar un SN (nombre seguro) para su ensamblaje cuando usa/codebase, pero descubrí que no es necesario; acaba de recibir una advertencia de la herramienta de línea de comandos regasm.exe.

El punto es que, desde el punto de vista de COM Interop, tenga cuidado con la versión .NET runtime de sus dependencias con respecto al .NET Framework al que se dirige.