Partager via

Problèmes connus avec la mise à jour des applications et des artefacts

  • Article

Mise à jour d'une application

La suppression ou la suppression d’un artefact ne le supprime pas de tous les emplacements

La suppression d'un artefact l'élimine des bases de données BizTalk Server de sorte qu'il n'apparaît plus ni dans la console d'administration, ni dans la liste des artefacts d'une application générée par la commande BTSTask ListApp. Il ne supprime pas l’artefact du registre Windows, du global assembly cache (GAC), d’un répertoire virtuel ou du système de fichiers, s’il existe à l’un de ces emplacements. Dans le cas des ports d'envoi, des groupes de ports d'envoi, des ports de réception et des emplacements de réception, qui n'existent que dans la base de données de gestion BizTalk, cette opération efface entièrement l'artefact.

Mise à jour d’un artefact

La suppression ou la modification de l’état d’un artefact peut empêcher une application de fonctionner

Lorsque vous ajoutez une référence d’une application à une autre et apportez des modifications à l’état d’un artefact dont dépend une autre application, ou que vous supprimez l’artefact, l’application qui a la dépendance ne fonctionne pas correctement. Pour plus d’informations sur la modification de l’état d’un artefact, consultez la section sur l’artefact approprié dans Gestion des artefacts (https://go.microsoft.com/fwlink/?LinkID=154725).

Les fichiers de stratégie .NET ne sont pas pris en charge

L’utilisation de fichiers de stratégie .NET n’est pas prise en charge dans BizTalk Server. En effet, il arrive que les fichiers de stratégie ne fonctionnent pas comme prévu. Ils redirigent .NET vers une version spécifique de l'assembly dans le GAC, mais BizTalk Server accède souvent aux données des assemblys et des artefacts à partir d'un cache ou de la base de données de gestion BizTalk. En fonction du type d'artefact, de la mise en cache et du redémarrage ou non des instances d'hôte, les fichiers de stratégie peuvent ne pas répondre correctement.

mise à jour d'un assembly

Les modifications apportées à un assembly peuvent ne pas prendre effet si l’hôte n’est pas arrêté

Les assemblys BizTalk doivent suivre les règles de contrôle de version .NET. La principale implication de tout ceci est qu'un projet BizTalk, une fois élaboré à partir d'une version donnée d'un autre projet .NET ou assembly (incluant des projets BizTalk), continue à utiliser cette version jusqu'à ce qu'il soit reconstruit à partir d'une version plus récente.

Un problème d'établissement de versions .NET se produit fréquemment pendant le développement lorsque les numéros de version d'un projet BizTalk ne sont pas modifiés et que l'assembly est redéployé sans arrêter et démarrer l'instance de l'hôte BizTalk dans laquelle les types sont chargés.

Quand le processus est exécuté à nouveau, les modifications ne prennent pas effet. Ceci est dû au mode de chargement en mémoire des assemblys .NET. Étant donné que l’hôte dispose déjà d’une copie en mémoire de l’assembly, il ne recharge pas l’assembly lorsqu’une nouvelle copie est placée dans le global assembly cache (GAC). Par exemple, si la version 1.0.0.0 d'un assembly avec orchestration est déployée et exécutée, et que des modifications sont apportées à l'orchestration mais que le numéro de version n'est pas modifié, les modifications ne prennent pas effet. Une fois l'instance de l'hôte arrêtée, la copie en mémoire de l'assembly est publiée. Ensuite, lorsque l'instance de l'hôte redémarre, elle recharge la copie nouvelle de l'assembly et reçoit les modifications. Si une nouvelle version a été déployée, par exemple la version 2.0.0.0, et qu’elle a été chargée, les modifications prennent effet.

La modification de la version de l’assembly peut interrompre la relation entre un assembly et les éléments qui le référencent par 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 des applications BizTalk (https://go.microsoft.com/fwlink/?LinkID=154210).
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 :

- Éviter de mettre à jour fréquemment les numéros de version pendant le processus de génération
- Retarder 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.