¿Cuál es la diferencia entre dependencias y agregar manualmente un dll / ocx en vs instalador 6?

Question

Estoy usando vs installer para crear un paquete de instalación para mi aplicación vb6. y el problema es que puedo ver que bajo el explorador de proyectos hay una lista de dependencias adjuntas a mi archivo exe.

alt text http://img505.imageshack.us/img505/9696/croppercapture259lr8 .png

y bajo el sistema de archivos en la vista de árbol de la máquina de destino, puedo almacenar el dll / ocx en una carpeta o en la carpeta del sistema de Windows [la ventana izquierda].

alt text http://img101.imageshack.us/img101/9224/croppercapture251qm1 .png

así que lo que no entiendo es ... ¿hay realmente alguna diferencia? si acabo de establecer las dependencias y no agregué el dll u ocx a la carpeta o la carpeta win sys, ¿el dll también se copia automáticamente?

Answer 1

No se garantiza que todos esos dlls estarán presentes en el sistema en el que se está instalando el software. Por lo tanto, deben incluirse en su instalador. A partir de ahí tienes dos opciones.

Puede instalarlos en las carpetas del sistema de Windows o en la carpeta de la aplicación. La diferencia es que si los instala en la carpeta de su aplicación, puede configurar las cosas en XP y Vista para que las diferentes versiones del software con diferentes versiones de los componentes puedan activarse y ejecutarse lado a lado. Instalarlos en la carpeta del sistema interrumpirá cualquier versión anterior que dependa de la versión anterior de los componentes.

La instalación en la carpeta de la aplicación rara vez no funciona si un componente depende de otros componentes que no se pueden actualizar. Cuando esto ocurre, generalmente ocurre con las bibliotecas de Microsoft. Han mejorado con los años en este tema.

Puede leer más sobre los problemas relacionados con la ejecución en paralelo aquí

Finalmente, las dependencias deben estar en su instalador para que se registren en el Registro de Windows. A diferencia de la mayoría de los ensamblados .NET, cualquier aplicación ActiveX / COM necesita tener el componente registrado para poder usarlo, incluso si está utilizando los tipos CreateObject y Variant para acceder a él.

Admito que todo el proceso es idiosincrásico y es una de las fuentes de las historias sobre DLL Hell. Comience con el artículo de MSDN, use wikipedia y, por supuesto, haga más preguntas aquí.

Answer 2

Por lo general, no debería tener un " dlls " carpeta debajo de la carpeta de la aplicación para un paquete de instalador normal, pero hay muchos factores involucrados (DLL estándar privados, COM sin registro, etc.). Sí, las dependencias se incluyen (a menos que las excluya ). Cada uno debe tener una propiedad que determine dónde se instalan en los sistemas de destino.

También tiene una serie de componentes en esa lista que no son redistribuibles de esta manera porque son componentes del sistema dependientes del sistema operativo, componentes MDAC o no tienen licencia para redist (por ejemplo, fm20.dll).

Lamentablemente, este es un ejemplo del tipo de paquete que puede conducir directamente a DLL Hell para los sistemas de sus usuarios. Arreglar esto puede significar investigar cada componente de MS en los artículos de MS KB para determinar qué puede o debe redistribuirse y cómo.

La implementación puede ser un negocio desordenado para hacerlo bien.