Gestion des versions du projet BizTalk Server

Article
05/04/2023

Lors du développement avec le .NET Framework, le contrôle de version est régi par un ensemble standard de règles qui permettent de réduire l’impact des modifications de numéro de version. Selon la façon dont une application ou un composant .NET Framework est déployé, les dépendances peuvent être gérées par un fichier de configuration d’application, via l’installation de XCOPY ou par d’autres mécanismes de déploiement .NET Framework. Comme le montrent les sections suivantes, BizTalk Server ajoute une complexité supplémentaire au contrôle de version et aux dépendances.

Implications d'un changement du numéro de version

Dans le développement .NET Framework, il est courant de mettre à jour le numéro de version de l’assembly vers le numéro de build actuel lorsqu’une build a lieu. Cependant, lors du développement d'une solution BizTalk, le changement du numéro de version de l'assembly peut entraîner une rupture de la relation entre l'assembly et les éléments dépendants qui font référence au fichier DLL en utilisant le numéro de version. Le tableau suivant répertorie les éléments qui font référence à un assembly BizTalk Server à l’aide de son numéro de version et de l’effet de la modification d’un numéro de version d’assembly.

Entité	Implications du changement dans le numéro de version de l'assembly
Fichiers de liaison	Le changement du numéro de version de l'assembly entraîne l'échec de tous les fichiers de liaison qui font référence à cet assembly. Cela est dû au fait que le fichier de liaison fait référence à l'assembly au moyen d'attributs qui comprennent le numéro de version. Vous pouvez mettre à jour les informations de version dans le fichier de liaison à l'aide du Bloc-notes ou d'un autre éditeur. Vous pouvez également redéployer la solution, puis régénérer le fichier de liaison à l’aide de la console d’administration BizTalk Server. Enfin, vous avez la possibilité d'utiliser des scripts pour automatiser le déploiement et la gestion des versions. Pour plus d’informations sur le déploiement, consultez Déploiement et gestion d’applications BizTalk.
Fichiers de définition du modèle de suivi BAM (.btt)	Le changement du numéro de version de l'assembly entraîne l'échec de tous les fichiers de définition du modèle de suivi BAM. Étant donné que les fichiers de suivi BAM sont dans un format binaire, ils ne peuvent pas être modifiés et doivent donc être régénérés. Si les modèles de suivi BAM sont nécessaires, il vous faut respecter l'une ou l'autre de ces instructions : - Évitez de mettre à jour fréquemment les numéros de version pendant le processus de génération. - Retardez la création des profils de suivi BAM jusqu’à ce que les numéros de version soient stables.
Services Web publiés à l'aide de l'Assistant Publication de services Web	Lorsque l’Assistant Publication des services web est utilisé pour produire une interface web ASP.NET, la version d’assembly de l’assembly BizTalk Server est incluse dans le code source ASP.NET. Le numéro de version de l’assembly est utilisé au moment de l’exécution par l’interface ASP.NET dans le cadre de la propriété bodyTypeAssemblyQualifiedName de l’opération de service Web. Si le numéro de version de l’assembly BizTalk Server change sans mettre à jour la propriété bodyTypeAssemblyQualifiedName, les opérations de service Web suivantes sont rejetées par BizTalk Server. Lorsque l'emplacement de réception utilise le pipeline XmlDefaultPipeline, l'abonnement se réfère au type de document. Ce dernier se sert des informations d'assembly incorporées et il échoue si l'assembly n'existe pas. Si le pipeline utilisé est PassThruPipeline (pipeline par défaut lorsqu'un port est exposé et que l'Assistant crée de lui-même l'emplacement de réception), l'abonnement ignore ces informations d'assembly incorporées.

Pour en savoir plus sur les assemblys BizTalk Server et le déploiement, consultez Assemblys BizTalk.

Traitement de la gestion des versions

Lors de la planification d'un projet, il existe deux options possibles :

utiliser une version d'assembly fixe pour un produit fini où seul le numéro de version du fichier est modifié par incrémentation ;
incrémenter la version de l'assembly ainsi que la version du fichier au cours du développement.

Vous trouverez ci-après un tableau comparatif détaillant ces deux possibilités.

Version d'assembly fixe / version de fichier dynamique	Version d'assembly dynamique / version de fichier fixe ou dynamique
Le numéro de version d'assembly est un numéro fixe. Le numéro de version du fichier est un numéro généré.	Le numéro de version d'assembly est un numéro généré. Le numéro de version du fichier est un numéro généré.
BizTalk Server runtime peut récupérer la version incorrecte de l’assembly si plusieurs assemblys sont installés.	BizTalk Server exécute toujours la dernière version de l’assembly, même si plusieurs assemblys sont installés.
Une seule version de la solution peut être déployée à tout moment.	Des versions différentes de la solution peuvent être déployées côte à côte. Néanmoins, d'autres aspects de la solution, tels que les définitions de schéma, peuvent entrer en conflit.
L'hôte BizTalk doit être redémarré pour forcer le chargement des assemblys mis à jour.	Force BizTalk Server à charger de nouveaux assemblys.
Cette configuration facilite la création d'un déploiement, car les fichiers qui référencent le numéro de version de l'assembly (par exemple, les fichiers de liaison et les modèles de suivi) n'ont pas besoin d'être modifiés.	Cette configuration rend la création d'un déploiement plus complexe, car les fichiers qui référencent le numéro de version de l'assembly doivent être mis à jour pour correspondre à la nouvelle version.

Si vous élaborez un prototype pour votre système ou que vous développez tout autre type de projet qui n'est pas destiné à la production, vous pouvez opter pour la solution qui consiste à utiliser un numéro de version d'assembly fixe et un numéro de version de fichier dynamique. Si l'application en cours d'élaboration n'est pas destinée à être livrée à un utilisateur final, vous pouvez rationnaliser les tâches de déploiement et réduire le nombre des dépendances rompues en fixant la version de l'assembly et en incrémentant le numéro de version de fichier. Pour un suivi des versions, n'oubliez pas d'incrémenter le numéro de version de fichier pour chaque version.

Si vous travaillez sur un projet destiné à un utilisateur final, il est préférable d'incrémenter le numéro de version d'assembly et, éventuellement, de stocker un numéro de version de fichier significatif. Cette solution demande un peu plus de travail, car il vous faut modifier les numéros de version et les dépendances associées. En revanche, elle garantit que les versions d'assembly utilisées sont bien les plus récentes. Grâce aux scripts de déploiement automatisés, vous pouvez réduire l'incidence de la gestion des versions sur votre système. Pour afficher des exemples de déploiement, consultez Déploiement d’applications (BizTalk Server dossier Exemples).

Notes

Choisissez le mécanisme de gestion des versions qui garantit que les fichiers appropriés sont livrés correctement et qui simplifie la maintenance et les améliorations.

Numérotation des versions de la fonction de mappage

Les assemblys .NET peuvent être appelés à partir d’une carte à l’aide du fonctoid Scripting . Cela apporte une grande flexibilité et permet au développeur de résoudre de nombreux problèmes relatifs au mappage personnalisé. En outre, une seule contrainte est imposée pour le mappage : il doit, de manière interne, faire référence au nom du type d'assembly ainsi qu'au numéro de version complet de l'assembly invoqué. Cela signifie que, si le numéro de version de l'assembly appelé par le mappage change, tous les liens qui font référence à cet assembly sont rompus.

Pour éviter ce type de difficulté lorsqu'il est nécessaire d'appeler des assemblys dans un mappage, il est conseillé de créer un assembly consacré à la fonctionnalité de mappage et de fixer le numéro de version de cet assembly. Ainsi, la version d'assembly des autres fonctions d'assistance peut être mise à jour sans supprimer les mappages.

Si un assembly référencé dans un mappage est modifié après le développement des mappages, pensez à mettre à jour le fichier de mappage hors de l'Éditeur de mappage pour répercuter les numéros de version mis à jour.

Pour utiliser le Bloc-notes afin de modifier le fichier de mappage permettant de mettre à jour les numéros de version

À l’aide du menu Démarrer , lancez le Bloc-notes.
Dans le Bloc-notes, dans le menu Fichier , cliquez sur Ouvrir. Dans la boîte de dialogue Ouvrir , sélectionnez le fichier de carte que vous souhaitez modifier, puis cliquez sur Ouvrir.
Dans le menu Edition , cliquez sur Rechercher. Dans la boîte de dialogue Rechercher , entrez Assembly=, puis cliquez sur Rechercher suivant.
S'il existe une référence de script à un assembly externe, le Bloc-notes doit rechercher un élément XML tel que :
```
<Script Language="ExternalAssembly" Assembly="Contoso.Scripts, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5145e4e089" Class="Contoso.Scripts" Function="CalculateValue" AssemblyPath="Contoso.Scripts.dll"/>  
```
Mettez à jour le numéro de version. S’il existe plusieurs instances, utilisez Remplacer dans le menu Edition .
Enregistrez le fichier .

Vous pouvez maintenant ouvrir le mappage à l'aide de l'Éditeur de mappage.

Voir aussi

Bonnes pratiques pour le déploiement d’une application BizTalk
Admin (dossier d’exemples BizTalk Server)
Déploiement et démarrage d’une nouvelle version d’une orchestration par programmation

Partager via