Problemas conocidos de actualización de aplicaciones y artefactos

Actualización de una aplicación

Quitar o eliminar un artefacto no lo quita de todas las ubicaciones

Al quitar o eliminar un artefacto, se elimina de las bases de datos del servidor BizTalk Server, de modo que ya no aparece en la consola de administración ni en la lista de artefactos de una aplicación generados por el comando BTSTask ListApp. No quita el artefacto del registro de Windows, la caché global de ensamblados (GAC), un directorio virtual o el sistema de archivos, si existe en cualquiera de estas ubicaciones. En el caso de los puertos de envío, grupos de puertos de envío, puertos de recepción y de las ubicaciones de recepción, que solo se encuentran en la base de datos de administración de BizTalk, esta operación elimina el artefacto completamente.

Actualización de un artefacto

Quitar o cambiar el estado de un artefacto puede hacer que una aplicación no funcione.

Cuando se agrega una referencia de una aplicación a otra y se realizan cambios en el estado de un artefacto en el que depende otra aplicación o se quita el artefacto, la aplicación que tiene la dependencia no funcionará correctamente. Para obtener más información sobre cómo cambiar el estado de un artefacto, consulte la sección sobre el artefacto adecuado en Administración de artefactos (https://go.microsoft.com/fwlink/?LinkID=154725).

No se admiten archivos de directiva de .NET

El uso de archivos de directiva de .NET no se admite en BizTalk Server. ya que es posible que los archivos de directiva no funcionen de la forma esperada. Los archivos de directiva redirigen a .NET a una versión de ensamblado especificada de la GAC, pero BizTalk Server suele tener acceso a los ensamblados y datos de artefactos desde una memoria caché o la base de datos de administración de BizTalk. Según el tipo de artefacto, la situación de almacenamiento en caché y el reinicio o no de las instancias de host, es posible que el archivo de directiva no realice lo que se desea.

Actualizar un ensamblado

Es posible que los cambios en un ensamblado no surtan efecto si el host no está detenido

Los ensamblados de BizTalk deben seguir las reglas de control de versiones de .NET. La repercusión principal de esto es que un proyecto de BizTalk, una vez generado con una versión concreta de otro proyecto o ensamblado .NET (incluidos los proyectos de BizTalk), sigue utilizando esa versión hasta que se vuelve a generar con una versión más reciente.

Durante el desarrollo, se produce un problema común relacionado con el control de versiones .NET cuando los números de versión de un proyecto de BizTalk no cambian y el ensamblado se vuelve a implementar sin detener e iniciar la instancia de host de BizTalk en la que se cargan los tipos.

Cuando se vuelve a ejecutar el proceso, los cambios no surten efecto. Esto se debe a la forma en la que se cargan los ensamblados .NET en memoria. Dado que el host ya tiene una copia en memoria del ensamblado, no vuelve a cargar el ensamblado cuando se coloca una nueva copia en la caché global de ensamblados (GAC). Por ejemplo, si se implementa y ejecuta la versión 1.0.0.0 de un ensamblado con una orquestación y se realizan cambios en la orquestación sin cambiar el número de versión, los cambios no surtirán efecto. Después de detener la instancia de host, la copia en memoria del ensamblado se libera; además, cuando la instancia de host se inicia de nuevo, carga la nueva copia del ensamblado y obtiene los cambios. Si se implementó una nueva versión, por ejemplo, la versión 2.0.0.0 y se cargó, los cambios surtirán efecto.

Cambiar la versión del ensamblado puede interrumpir la relación entre un ensamblado y los elementos que hacen referencia a él por 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 (https://go.microsoft.com/fwlink/?LinkID=154210).
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: - Evitar la actualización frecuente de números de versión durante el proceso de compilación - Retrasar la compilació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 de BizTalk Server cambia sin actualizar la propiedad bodyTypeAssemblyQualifiedName, BizTalk Server rechazará 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.