Control de versiones del proyecto de BizTalk Server
Al desarrollar con .NET Framework, el control de versiones se rige por un conjunto estándar de reglas que funcionan para minimizar el impacto de los cambios en el número de versión. En función de cómo se implemente una aplicación o un componente de .NET Framework, las dependencias se pueden controlar mediante un archivo de configuración de aplicación, mediante la instalación de XCOPY o mediante otros mecanismos de implementación de .NET Framework. Como se muestra en las secciones siguientes, BizTalk Server agrega complejidad adicional al control de versiones y las dependencias.
Repercusiones del cambio de los números de versión
En el desarrollo de .NET Framework, es habitual actualizar el número de versión del ensamblado al número de compilación actual cuando se realiza una compilación. Sin embargo, cuando se desarrolla una solución de BizTalk, al cambiar el número de versión de ensamblado se puede romper la relación entre un ensamblado y los elementos dependientes que hacen referencia a DLL por su número de versión de ensamblado. En la tabla siguiente se enumeran los elementos que hacen referencia a un ensamblado de BizTalk Server mediante su número de versión y el efecto de cambiar un número de versión de ensamblado.
| Entidad | Efecto de cambiar el número de versión del ensamblado |
|---|---|
| Archivos de enlace | Al cambiar el número de versión de ensamblado se producen errores en cualquier archivo de enlace existente que haga referencia al ensamblado. Esto se debe a que el archivo de enlace hace referencia al ensamblado mediante atributos incluyendo el número de versión. Puede actualizar la información de versión en el archivo de enlace mediante el Bloc de notas u otro editor. También puede volver a implementar la solución y, a continuación, volver a generar el archivo de enlace mediante la consola de administración de BizTalk Server. Por último, puede utilizar las secuencias de comandos para automatizar la implementación y el control de versiones. Para obtener más información sobre la implementación, vea Implementación y administración de aplicaciones de BizTalk. |
| Archivos (.btt) de definición de perfiles de seguimiento de BAM | Al cambiar el número de versión de ensamblado se producen errores en cualquier archivo de definición de perfiles de seguimiento de BAM existente. Los archivos de seguimiento de BAM están en un formato de archivo binario por lo que no se pueden editar y, en su lugar, se deben volver a generar. Si se requieren perfiles de seguimiento de BAM, es posible que sea necesario realizar una de las siguientes acciones: - Evite actualizar con frecuencia los números de versión durante el proceso de compilación. - Retrasar la creación de perfiles de seguimiento de BAM hasta que los números de versión sean estables. |
| Servicios Web publicados mediante el Asistente para publicación de servicios Web | Cuando se usa el Asistente para publicación de servicios web para generar una interfaz web de ASP.NET, la versión del ensamblado de BizTalk Server se incluye en el código fuente de ASP.NET. La interfaz de ASP.NET usa el número de versión del ensamblado en tiempo de ejecución como parte de la propiedad bodyTypeAssemblyQualifiedName de la operación de servicio web. Si el número de versión del ensamblado BizTalk Server cambia sin actualizar la propiedad bodyTypeAssemblyQualifiedName, BizTalk Server rechazarán las operaciones de servicio web posteriores. Si la ubicación de recepción utiliza XmlDefaultPipeline, la suscripción se basa en el tipo de documento. Utiliza la información de ensamblado integrada y si el ensamblado no existe, se producirán errores. Si utiliza PassThruPipeline (que es la opción predeterminada si expone un puerto y permite que el asistente cree la ubicación de recepción), la suscripción omite esta información de ensamblado integrada. |
Para obtener más información sobre BizTalk Server ensamblados e implementación, vea Ensamblados de BizTalk.
Enfoques para el control de versiones
Cuando se planifica un proyecto, tiene las siguientes opciones:
Elegir una versión de ensamblado fija para una entrega determinada e incrementar solo el número de versión del archivo.
Incrementar tanto la versión de ensamblado como la de archivo durante el desarrollo.
En la siguiente tabla se comparan estos enfoques.
| Versión de ensamblado fija, versión de ensamblado dinámica | Versión de ensamblado dinámica, versión de archivo fija o dinámica |
|---|---|
| Número de versión de ensamblado = Número fijo Número de versión de archivo = Número de versión de compilación |
Número de versión de ensamblado = Número de versión de compilación Número de versión de archivo = Número de versión de compilación |
| BizTalk Server tiempo de ejecución puede elegir la versión incorrecta del ensamblado si hay varios ensamblados instalados. | BizTalk Server siempre ejecuta la versión más reciente del ensamblado, incluso si se instalan varios ensamblados. |
| En cualquier momento solo se puede implementar una versión de solución. | Se pueden implementar de forma paralela diferentes versiones de la solución (aunque otros aspectos de la solución, como las definiciones de esquema, pueden entrar en conflicto). |
| Debe reiniciarse BizTalk Host para forzar la carga de ensamblados actualizados. | Obliga a BizTalk Server a cargar nuevos ensamblados. |
| Requiere menos trabajo para crear una implementación nueva ya que no es necesario editar los archivos que hacen referencia al número de versión (por ejemplo, archivos de enlace y perfiles de seguimiento). | Requiere más trabajo para la implementación ya que es necesario mantener actualizados con la versión nueva los archivos que hacen referencia al número de versión del ensamblado. |
Puede elegir utilizar el enfoque de versión de ensamblado fija o de versión de archivo dinámica si va a crear un prototipo de un sistema o a desarrollar cualquier otro tipo de proyecto que no sea de envío. Si no desea entregar la aplicación a un usuario final, puede aumentar la eficacia de las tareas de implementación y reducir las dependencias interrumpidas al fijar la versión de ensamblado e incrementar el número de versión de archivo. Para el seguimiento de versiones, no olvide aumentar el número de versión del archivo de cada compilación.
Si crea un proyecto que se va a entregar a un usuario final, debería considerar aumentar el número de versión de ensamblado y, de forma opcional, almacenar un número de versión de archivo significativo. Mientras que este enfoque provoca un esfuerzo adicional al tener que modificar los números de versión de compilación y las dependencias asociadas, asegura que se utilizan las últimas versiones de los ensamblados. Al utilizar secuencias de comandos de implementación automatizadas, puede disminuir la influencia del control de versiones. Para ver ejemplos de implementación, consulte Implementación de aplicaciones (BizTalk Server carpeta de ejemplos).
Nota
Debería elegir el mecanismo de control de versiones que asegura que se entregan los archivos adecuados y simplifica el mantenimiento y la mejora.
Numeración de versiones en la función de asignación
Los ensamblados .NET se pueden invocar desde dentro de un mapa mediante el functoid Scripting . Esto proporciona una gran flexibilidad y permite al programador resolver problemas de asignación personalizada muy diferentes. También impone una restricción única en el mapa; debe hacer referencia internamente no solo al nombre del tipo de ensamblado, sino también al número de versión completo del ensamblado que se invoca. Como consecuencia, si cambia el número de versión del ensamblado al que llama la asignación, se interrumpirán todos los enlaces que hacen referencia al ensamblado.
Para evitar este problema recomendamos que si es necesario que una asignación llame a los ensamblados, se cree un ensamblado específico para mantener solo la funcionalidad de asignación y se fije un número de versión de ensamblado para este ensamblado. De este modo, otras funciones del asistente pueden actualizar la versión de ensamblado sin interrumpir las asignaciones.
Si se cambia un ensamblado al que hace referencia una asignación tras el desarrollo de la asignación, debería actualizar el archivo de asignaciones fuera del editor de asignaciones para que refleje los números de versiones actualizados.
Realice lo siguiente para modificar mediante el Bloc de notas el archivo de asignaciones y que refleje los números de versiones actualizados:
Con el menú Inicio , inicie el Bloc de notas.
En el Bloc de notas, en el menú Archivo , haga clic en Abrir. En el cuadro de diálogo Abrir , seleccione el archivo de mapa que desea modificar y, a continuación, haga clic en Abrir.
En el menú Edición , haga clic en Buscar. En el cuadro de diálogo Buscar , escriba Assembly=y, a continuación, haga clic en Buscar siguiente.
Si hay una referencia de secuencia de comandos a un ensamblado externo, el Bloc de notas debería buscar un elemento XML como el siguiente:
<Script Language="ExternalAssembly" Assembly="Contoso.Scripts, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5145e4e089" Class="Contoso.Scripts" Function="CalculateValue" AssemblyPath="Contoso.Scripts.dll"/>Actualice el número de versión. Si hay varias instancias, use Reemplazar en el menú Editar .
Guarde el archivo.
Podrá abrir la asignación mediante el editor de asignaciones.
Consulte también
Procedimientos recomendados para implementar una aplicación de BizTalk
Admin (carpeta de ejemplos de BizTalk Server)
Implementación e inicio de una nueva versión de una orquestación mediante programación