Estoy buscando las mejores prácticas en la construcción de múltiples proyectos visuales básicos (todos los dll). Tenemos múltiples proyectos, y nuestro producto final será un dll. Ahora, un proyecto usa 2 otros proyectos, y otro se refiere a otro proyecto. ¿Deberían los proyectos hacer referencia a los archivos vbp, o al dll? Si hacen referencia a archivos vbp, ¿cómo construir todos los proyectos?Cómo hacer desarrollo y construir en Visual Basic 6.0
A menos que esté gestionando específicamente las librerías de tipos externas de VB, debe utilizar referencias de proyecto. Si hace referencia a los archivos y modifica la interfaz pública de varias maneras, VB generará nuevos id para varias piezas en la biblioteca de tipos, lo que dará como resultado errores de tipo de desajuste.
Puede utilizar la configuración Preservar compatibilidad para ayudar a aliviar esto. Asegúrese de usar al menos nivel de proyecto (Si está haciendo COM + entonces querrá el binario basado en una versión ya compilada del dll)
En cuanto a la compilación, puede compilar un archivo de solución (desde hace mucho tiempo) ya que incluso tenía instalado Vb6, pero creo que eran archivos .vbg).
De vuelta en el día usamos Visual Build, y también Visual Make que admitió la compilación de los archivos de la solución.
Compila cada proyecto por separado comenzando en el nivel más bajo y ascendiendo por la cadena.
El gran problema de las compilaciones con VB6 generalmente se debe a problemas de compatibilidad. Los peores problemas de compatibilidad caso, la solución es más o menos le gusta esta
Build A (con A siendo la referencia de todos los demás)
Copiar A en el directorio de compatibilidad
Construir B que hacen referencia a un
B Copiar en el directorio de compatibilidad
Construir C que hace referencia a B y A Cop
y C en el directorio de compatibilidad.
y así sucesivamente.
Esto se debe a que las tablestablas de la DLL COM utilizan INCLUDE para agregar las tablestablas de los proyectos a los que hacen referencia. Puede ver los Type Libs de una DLL COM de VB6 utilizando la herramienta OLE View que viene con Visual Studio 6.0.
Muchas veces la adición de métodos o propiedades hará que la DLL no se pueda compilar porque el Método MS de configurar las Typelibs no las hace compatibles con binarios. Esto falla cuando la adición está permitida bajo las reglas de compatibilidad binaria.
La solución que funciona el 90% del tiempo es poner siempre la última versión de los archivos DLL referencia en el directorio de compatibilidad.
Una vez que tenga un buen conjunto, puede hacer que un generador automático lo use para construir el proyecto automáticamente.
Tenga en cuenta que este problema ocurre solo cuando agrega algo que las otras DLL hacen referencia y necesitan mantener la compatibilidad binaria.
Necesita un sistema para asegurarse de que todos tengan el conjunto correcto de DLL de compatibilidad para compilar.
Después de algunos años con VB6, nuestros proyectos tendían a estructurarse así:
Todo el origen del proyecto (proyecto y fuente) organizado en la carpeta de origen.
\ proyecto \
fuente \ proyecto \ source \ Project1 \
\ proyecto \ source \ project2 \
...
Todos los binarios (.dll y .exe) en una carpeta bin.
\ project \ bin \
Todos los archivos .dll configurados como binarios compatibles con el archivo resultante en el directorio de una sola bandeja.
Después construcción inicial para hacer el establo binarycomptible, cada proyecto de construcción no habría ruptura hacerse mediante el uso de un archivo de comandos sencilla build.cmd colocado en la carpeta por encima de la carpeta de origen, tal como esto:
"c: \ Archivos de programa \ Microsoft Visual Studio \ VB98 \ VB6.EXE "/ M. \ Source \ project1 \ proj1.vbp
" c: \ Archivos de programa \ Microsoft Visual Studio \ VB98 \ VB6.EXE "/ M. \ Source \ project2 \ proj2.vbp
"c: \ archivos de programa \ Microsoft Visual Studio \ VB98 \ VB6.exe"..../M \ source \ proyecto3 \ proj3.vbp
del \ bin \ * exp
del \ bin \ *. lib
El orden de compilación debe ser del orden de dependencia.
Siempre que ocurra un cambio de rotura, el proyecto de VB dependiente debe refrendarse al nuevo binario.
Sin romper los cambios, build.cmd por lo general hizo el trabajo.