Buildprocess para proyectos empresariales ActiveX / COM / VB6

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 processs de compilation automatizados y SCM. Busqué intensamente grandes partes de la web para get 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 reference contiene la reference mediante una identificación de interfaz única. Cuando recomstack el componente al que se hace reference, la identificación puede cambiar y la reference ya no es válida. El principal problema aquí es que el iid está comstackdo en el binary. Entonces, cuando no quiero registrar los files comstackdos en el control de la versión, cada desarrollador debe comstackr sus propias versiones y get otros identificadores.

Cuando quiero verificar el origen en una máquina de compilation limpia para comstackr el sistema, es simplemente imposible, porque todas las references son inválidas (sin files binarys, sin identificadores de interfaz).

Me pregunto si hay algunas mejores prácticas flotando alnetworkingedor, ¿cómo configurar un sistema automatizado de compilation para proyectos COM (VB6)?

Editar: Sí, estoy al tanto de la configuration de compatibilidad. Pero tome el escenario, donde quiero build el sistema wohle en una máquina de construcción limpia sin binarys. Cuando dice que un proyecto es binary compatible, debe proporcionar el binary con el que el proyecto es compatible.

Creo que tengo que escribir una herramienta de compilation personalizada, que modifica las references y la configuration de compatibilidad en los files del proyecto antes y después de comstackr los proyectos.

Debido a que VB6 / COM es una tecnología muy amplia, estaba pensando que tiene que haber una solución list para usar.

Normalmente comstackmos con compatibilidad binaria. Cuando modificamos la interfaz pública, de un componente, comstackmos 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 reference a la compatibilidad del proyecto, volver a comstackrlos y volver a la compatibilidad binaria. Ese es el process principal que quiero automatizar.

Visual Build Pro . Si todavía estás atascado en tierra VB6, y tienes que build productos profesionales, te recomiendo que estudies este producto. Tiene una versión de testing gratuita y vale cada centavo (además hace un trabajo bastante bueno de continuous integration para .Net y otras plataforms). 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.

Puede decirle a VB6 que reutilice GUID (LIBID de CLSID de IID, etc.) cambiando la configuration de compatibilidad del proyecto de "Sin compatibilidad" a "Compatibilidad binaria". Puede encontrar estas configuraciones en Proyecto-> Propiedades de su proyecto . La configuration de compatibilidad se encuentra en la pestaña Componente de la window 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 configuration, no se aplica compatibilidad. Visual Basic crea nuevos identificadores de interfaz e ID de class cada vez que comstack o comstack su proyecto. Cada versión construida solo se puede usar con aplicaciones creadas para trabajar con esa compilation específica del componente.

Compatibilidad del proyecto

Con esta configuration, 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 testing aún puedan referirse al proyecto de componente. Esta configuration es para mantener la compatibilidad durante la testing. Por lo tanto, una vez que se libera el componente, se comporta de la misma manera que la configuration Sin compatibilidad.

Compatibilidad Binaria

Cuando comstack su proyecto, Visual Basic solo crea nuevos ID de Clase e Interfaz cuando sea necesario. Conserva la class y los ID de interfaz de las versiones anteriores para que los progtwigs comstackdos 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 configuration que necesita usar.

Parece que actualmente está comstackndo 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:

  • Comstack cada proyecto una vez sin compatibilidad

  • Guarde estas versiones "limpias" en una carpeta a la que las personas que realizan las comstackciones puedan acceder fácilmente, como el recurso compartido de networking, o póngalas en control de fuente.

  • Regrese y cambie todos los proyectos a "Compatibilidad binaria" y señale el "Archivo compatible" a la versión correspondiente que acaba de save en la networking / en el control de origen (no apunte el file compatible a la misma ruta en la que está comstackndo project to. El file compatible debe ser una copy separada del componente original que no cambiará. Solo existe para que VB pueda copyr los ID de ese file en su proyecto cuando lo vuelva a comstackr).

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 class (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 file compatible en versiones futuras. Sin embargo, es importante tener en count que solo debe comenzar de nuevo cuando cambien sus interfaces de class (properties y methods). 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 comstack todos nuestros proyectos para nosotros, y una de las principales características de la herramienta es que puede reparar automáticamente las references de proyectos rotos entre proyectos. Dado que la herramienta de compilation lo arregla para nosotros, hay less 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 recomstackr fácilmente un solo componente y networkingistribuirlo 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 comstackr y networkingistribuir 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 class y las ID de interfaz identifican de manera única una class o interfaz. Si sus classs y / o interfaces no han cambiado entre versiones, entonces no hay razón para generar nuevos ID para esas classs e interfaces (de hecho, entonces la misma class 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 logging. Si siempre está implementando nuevos componentes para clientes que no son compatibles con versiones anteriores, cada nueva versión agregará nueva información al logging. Cada nueva interfaz e identificación de class debe registrarse, entre otras cosas. Si conserva todo lo compatible con Binary, entonces el instalador solo tiene que agregar las keys de logging en un solo lugar, ya que las identificaciones de class 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.

Como sugiere Mike Spross, debes usar la compatibilidad binaria. Puedes (y deberías) build en una máquina limpia. Para ello, conserve una copy de los binarys de producción actuales (ActiveX DLL y OCX) en un directory "compatible" en su sistema de control de origen. Todos los proyectos deben hacer reference a esta copy cuando select Comestibilidad binaria. Por ejemplo, coloque los nuevos binarys en … \ Release y los binarys compatibles en vivo en … \ Compatible. Cuando la nueva versión entra en producción, copy 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 class. Recuerde que en COM una interfaz es inmutable. Si realiza el cambio más leve 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 superset 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 networkingirige todas las references 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 resources 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.