net - Buildprocess para proyectos empresariales ActiveX/COM/VB6
visual basic 6.0 empresarial (3)
Hemos desarrollado un sistema de software que utiliza la tecnología ActiveX / COM (VB6) de microsoft. En el último año, cada vez me interesan más los procesos de compilación automatizados y SCM. Busqué intensamente grandes partes de la web para obtener información sobre las mejores prácticas sobre cómo hacer scm con sistemas de software basados en COM.
El "problema" con COM es que un componente de referencia contiene la referencia mediante una identificación de interfaz única. Cuando recompila el componente al que se hace referencia, la identificación puede cambiar y la referencia ya no es válida. El principal problema aquí es que el iid está compilado en el binario. Entonces, cuando no quiero registrar los archivos compilados en el control de la versión, cada desarrollador debe compilar sus propias versiones y obtener otros identificadores.
Cuando quiero verificar el origen en una máquina de compilación limpia para compilar el sistema, es simplemente imposible, porque todas las referencias son inválidas (sin archivos binarios, sin identificadores de interfaz).
Me pregunto si hay algunas mejores prácticas flotando alrededor, ¿cómo configurar un sistema automatizado de compilación para proyectos COM (VB6)?
Editar: Sí, estoy al tanto de la configuración de compatibilidad. Pero tome el escenario, donde quiero construir el sistema wohle en una máquina de construcción limpia sin binarios. Cuando dice que un proyecto es binario compatible, debe proporcionar el binario con el que el proyecto es compatible.
Creo que tengo que escribir una herramienta de compilación personalizada, que modifica las referencias y la configuración de compatibilidad en los archivos del proyecto antes y después de compilar los proyectos.
Debido a que VB6 / COM es una tecnología muy amplia, estaba pensando que tiene que haber una solución lista para usar.
Normalmente compilamos con compatibilidad binaria. Cuando modificamos la interfaz pública, de un componente, compilamos con la compatibilidad del proyecto. Pero cuando cambia la interfaz de un componente básico que es utilizado por muchos otros componentes, tiene que cambiar manualmente todo el proyecto de referencia a la compatibilidad del proyecto, volver a compilarlos y volver a la compatibilidad binaria. Ese es el proceso principal que quiero automatizar.
Visual Build Pro . Si todavía estás atascado en tierra VB6, y tienes que construir productos profesionales, te recomiendo que estudies este producto. Tiene una versión de prueba gratuita y vale cada centavo (además de que hace un trabajo bastante bueno de integración continua para .Net y otras plataformas). Nos ha salvado del infierno de DLL en cada lanzamiento desde que comenzamos a usarlo. No hay otra forma que yo sepa de crear una caja de construcción decente en VB6.
Como sugiere Mike Spross, debes usar la compatibilidad binaria. Puedes (y deberías) construir en una máquina limpia. Para ello, conserve una copia de los binarios de producción actuales (ActiveX DLL y OCX) en un directorio "compatible" en su sistema de control de origen. Todos los proyectos deben hacer referencia a esta copia cuando seleccione Comestibilidad binaria. Por ejemplo, coloque los nuevos binarios en ... / Release y los binarios compatibles en vivo en ... / Compatible. Cuando la nueva versión entra en producción, copia todo desde ... / Release to ... / Compatible. De esta forma, mantendrá la compatibilidad pasando de una versión a otra.
En el modo de compatibilidad binaria, VB creará un nuevo IID si agrega un nuevo método a su clase. Recuerde que en COM una interfaz es inmutable. Si realiza el menor cambio en una interfaz, está creando algo nuevo. VB observa esta regla de COM, pero usa algunos espejos para evitar que se rompa el código del cliente anterior. Como VB "sabe" que la nueva interfaz es un superconjunto 100% de la interfaz anterior (esto es lo que garantiza la compatibilidad binaria), puede usar "reenvío de interfaz". El reenvío de la interfaz simplemente redirige todas las referencias de la interfaz anterior a la nueva. Sin este truco, tendría que crear nuevas versiones (con diferentes nombres y CLSID) de cualquier componente de ActiveX que modifique. ¡DLL Hell se convertiría en DLL Armargeddon!
VB almacena toda la información de reenvío de interfaz en los recursos de su componente. Cuando registra el componente, escribe todos los IID de la interfaz en HKCR / Interface. Las interfaces más antiguas tendrán información de reenvío en ellas. Solo la interfaz "real" se referirá a un coclass real.
Puede decirle a VB6 que reutilice GUID (LIBID de CLSID de IID, etc.) cambiando la configuración de compatibilidad del proyecto de "Sin compatibilidad" a "Compatibilidad binaria". Puede encontrar estas configuraciones en Proyecto-> Propiedades de su proyecto . La configuración de compatibilidad se encuentra en la pestaña Componente de la ventana Propiedades del proyecto. Hay tres opciones:
- Sin compatibilidad
- Compatibilidad del proyecto
- Compatibilidad Binaria
Esto es lo que dice MSDN sobre ellos:
Sin compatibilidad
Con esta configuración, no se aplica compatibilidad. Visual Basic crea nuevos identificadores de interfaz e ID de clase cada vez que compila o compila su proyecto. Cada versión construida solo se puede usar con aplicaciones creadas para trabajar con esa compilación específica del componente.Compatibilidad del proyecto
Con esta configuración, puede hacer que su proyecto sea compatible con un proyecto de componente específico. Mientras se genera información de biblioteca de tipo nuevo, se mantiene el identificador de biblioteca de tipo para que los proyectos de prueba aún puedan referirse al proyecto de componente. Esta configuración es para mantener la compatibilidad durante la prueba. Por lo tanto, una vez que se libera el componente, se comporta de la misma manera que la configuración Sin compatibilidad.
Compatibilidad Binaria
Cuando compila su proyecto, Visual Basic solo crea nuevos ID de Clase e Interfaz cuando sea necesario. Conserva la clase y los ID de interfaz de las versiones anteriores para que los programas compilados con una versión anterior sigan funcionando. Si realiza un cambio que dará como resultado una versión incompatible, Visual Basic lo advertirá. Si desea mantener la compatibilidad con las versiones antiguas y publicadas de un componente ActiveX, esta es la configuración que necesita usar.
Parece que actualmente está compilando sin compatibilidad . Como dice el artículo de MSDN, debe usar la compatibilidad binaria para mantener las versiones más nuevas de sus componentes compatibles con las versiones anteriores. Puedes hacer esto ahora haciendo lo siguiente:
Compila cada proyecto una vez sin compatibilidad
Guarde estas versiones "limpias" en una carpeta a la que las personas que realizan las compilaciones puedan acceder fácilmente, como el recurso compartido de red, o póngalas en control de fuente.
Regrese y cambie todos los proyectos a "Compatibilidad binaria" y apunte el "Archivo compatible" a la versión correspondiente que acaba de guardar en la red / en el control de código fuente (no apunte el archivo compatible a la misma ruta que está compilando project to. El archivo compatible debe ser una copia separada del componente original que no cambiará. Solo existe para que VB pueda copiar los ID de ese archivo en su proyecto cuando lo vuelva a compilar).
Cada vez que recompile sus proyectos, reutilizarán los GUID de las versiones compatibles (originales) de los componentes.
EDITAR: Como mencionó Joe en los comentarios, también debe reconocer cuándo han cambiado sus interfaces de clase (es decir, cuando una interfaz cambia lo suficiente como para que pueda mantener la compatibilidad binaria con las versiones anteriores). Cuando esto ocurre, quiere hacer un corte limpio de las versiones anteriores de los componentes: recompile una nueva versión "limpia" (es decir, sin compatibilidad) y use esa nueva versión como su archivo compatible en versiones futuras. Sin embargo, es importante tener en cuenta que solo debe comenzar de nuevo cuando cambien sus interfaces de clase (propiedades y métodos). De hecho, VB le avisará cuando un proyecto ya no sea compatible con la versión anterior del componente.
Si quieres vivir al límite ...
Donde trabajo, tendemos a (ab) usar Sin Compatibilidad en la mayoría de nuestros proyectos, aunque en realidad no es la manera correcta de hacer las cosas ( debe usar la Compatibilidad Binaria). En nuestra empresa se adquirió la pereza, porque contamos con una herramienta de construcción automatizada que compila todos nuestros proyectos para nosotros, y una de las principales características de la herramienta es que puede reparar automáticamente las referencias de proyectos rotos entre proyectos. Dado que la herramienta de compilación lo arregla para nosotros, hay menos incentivos para usar la compatibilidad binaria.
Por qué la compatibilidad binaria es mejor (o ... por qué no debes hacer lo que hacemos)
Algunas razones por las que la compatibilidad binaria suele ser la mejor opción:
Microsoft dice que sí
Si todos sus componentes son compatibles con versiones anteriores de su software, puede recompilar fácilmente un solo componente y redistribuirlo a sus clientes. Esto hace que las correcciones de errores / parches sean más fáciles de implementar. Si usa Sin compatibilidad en sus proyectos, tendrá que volver a compilar y redistribuir toda la aplicación cada vez que deba salir un parche pequeño, porque los componentes más nuevos (probablemente) no funcionarán con los componentes más antiguos.
Usted está haciendo su parte para mantener el estándar COM: en COM, se supone que las ID de clase y las ID de interfaz identifican de manera única una clase o interfaz. Si sus clases y / o interfaces no han cambiado entre versiones, entonces no hay razón para generar nuevos ID para esas clases e interfaces (de hecho, entonces la misma clase tendría múltiples ID). La compatibilidad binaria le permite mantener las mismas ID en todas las construcciones, lo que significa que está siendo un buen ciudadano y siguiendo las convenciones COM.
Menos ruido de registro. Si siempre está implementando nuevos componentes para clientes que no son compatibles con versiones anteriores, cada nueva versión agregará nueva información al registro. Cada nueva interfaz e identificación de clase debe registrarse, entre otras cosas. Si conserva todo lo compatible con Binary, entonces el instalador solo tiene que agregar las claves de registro en un solo lugar, ya que las identificaciones de clase y de interfaz no cambiarán.
Si está exponiendo una API o componente público que consumen otras aplicaciones de terceros, definitivamente querrá utilizar la compatibilidad binaria para que no rompa el software de terceros que depende de su código.