Lo que podría causar el error de tiempo de ejecución Vb6 430

Question

Tengo un dll COM escrito en vb6. Cuando trato de crear un nuevo objeto de un módulo de clase desde este dll obtengo un error 430 de ejecución del temporizador: la clase no admite la automatización o no admite la interfaz esperada. Lo interesante es que esto ocurre solo desde fuera del IDE, cuando estoy depurando desde dentro del IDE no se produce ningún error y el nuevo objeto de la clase se crea con éxito. ¿Cuál puede ser la causa?

En general, de vez en cuando recibo este tipo de errores en las DLL de COM. ¿Cuál es la mejor manera de depurar problemas COM? ¿Cómo puedo saber la ruta de la DLL que se está utilizando cuando se está ejecutando un programa?

Answer 1

Si este proyecto está completamente en VB6. La causa probable de esto es que el EXE tiene una copia del archivo DLL binario en su directorio. Cuando disparas usa esa copia en lugar de la copia compilada. Cuando agrega métodos o clases, EXE se vuelve incompatible con la DLL anterior. Si hiciste una corrección de error o simplemente trabajaste con el código interno, entonces EXE se ejecutará pero usó el DLL anterior.

Establezca su DLL a la compatibilidad binaria. Asegúrate de tener un directorio compatible. Ponga la DLL de la última versión allí. Apunte la compatibilidad binaria a esa DLL. Asegúrate de que tu EXE compila en su directorio de proyectos. Ejecute el EXE desde su directorio de proyecto. De esa forma usará la DLL que compiló. Necesita escribir una utilidad para que pueda compilar cada proyecto por separado. Pruebe su configuración con Virtual PC u otra computadora.

Todos estos pasos ayudarán a evitar DLL Hell. Mi propio proyecto tiene dos docenas de proyectos ActiveX en 6 capas. Cuando adopté lo anterior mi DLL Los problemas del infierno cayeron a casi nada.

Answer 2

Esto es casi seguro un problema de versiones, a veces conocido como "DLL hell".

El trasfondo es que el mundo .NET está explícitamente diseñado para permitir que las interfaces evolucionen manteniendo el mismo nombre. Pero en el mundo COM, las interfaces se consideran inmutables.

Cuando trabaja en el IDE, Visual Studio está creando un nuevo contenedor COM Interop para el dll COM cada vez que ejecuta su solución. Pero a menos que libere y reemplace su solución completa en todo momento, incluido un contenedor COM Interop completamente nuevo, se encontrará con un problema de control de versiones, donde el código .NET espera una interfaz COM pero ve una diferente.

EDIT: Por alguna razón, asumí que está tratando de usar el componente COM de un componente .NET. Si la solución completa es realmente VB6, entonces la solución del Sr. Conley es el enfoque recomendado. Here's a good link que discute el problema.

Answer 3

Lectura en proyecto binario vs compatible.

Si tiene una dll compartida, debe tener cuidado y usar compatibilidad binaria. De esta forma, VB6 mantendrá la misma firma/interfaz COM entre compilaciones. Debe tener una copia de la DLL liberada para VB6 para compararla. Por lo general, tengo una carpeta separada para los archivos binarios publicados. La restricción con compatibilidad binaria es que no puede eliminar propiedades o métodos públicos y no puede cambiar sus firmas. Puede agregar nuevas propiedades y métodos.

Utilice la compatibilidad de proyectos si tiene que realizar cambios bruscos (como eliminar métodos públicos antiguos); sin embargo, si lo hace, tendrá que volver a compilar todas las demás aplicaciones que usen la DLL compartida.