Gestion de version BizTalk automatique dans mon processus de construction

Question

Dans toutes mes autres applications .net, mon processus de construction (un mélange de tâches nant et personnalisées) met automatiquement à jour AssemblyInfo.cs [AssemblyVersionAttribute] avec le numéro de build actuel avant l'appel à msbuild, estampillage dans le numéro de construction dans le numéro de version.

Je travaille actuellement sur mon premier projet BizTalk et j'aimerais faire la même chose avec les numéros de version des assemblages BizTalk, mais j'ai eu des problèmes! Tout d'abord, les numéros de version de l'assemblage sont stockés dans les fichiers btproj, donc j'ai fait un peu de googling et trouvé www.codeplex.com/biztalk qui ressemblait à la réponse à mon problème, mais il y a un problème plus profond!

J'ai un projet pour mes schémas et un autre pour mes pipelines, le projet pipelines référence mon projet schémas car j'ai un fichier plat dis/assemblers. Le problème survient lorsque je mets à jour les numéros de version, car leur mise à jour, même depuis Visual Studio, ne met pas à jour les références des composants de pipeline aux schémas. Par conséquent, si je mets à jour manuellement tous les numéros de version dans l'EDI VS de 1.0.0.0 à 1.1.0.0, la construction échoue car les fichiers plats dis/assemblers des composants de pipeline font toujours référence à l'ancienne version 1.0.0.0 des schémas! Ils ne mettent pas à jour automatiquement!

Est-ce un processus manuel de mise à jour des numéros de version des projets BizTalk dans les pages de propriétés, puis de construction des projets et de mise à jour manuelle des références dans les propriétés de tous les composants pipeline?

Cela signifie que mon processus de construction ne peut pas contrôler la partie du numéro de version de mes numéros de version!

Ou existe-t-il une meilleure méthode de gestion des numéros de version des assemblys BizTalk?

Answer 1

Je suis désolée de vous avoir déçue, mais je suis tombée sur la route que j'avais à abandonner. Je suppose qu'il pourrait être possible de l'atteindre mais cela nécessiterait beaucoup de changements à la fois aux fichiers de liaison et aux autres fichiers XML (comme vous l'avez mentionné et même plus si vous avez publié des services, etc.).

Peut-être qu'il pourrait être possible d'encapsuler tous ces changements nécessaires dans une étape de construction (une étape MSBuild ou similaire dans d'autres cadres de construction) - ce serait utile!

Answer 2

Épuisé, pensé que ce pourrait être le cas. Peut-être que les projets BizTalk 2009 joueront mieux lors de la mise à jour des références lors de la modification des numéros de version. J'ai commencé à le parcourir et à l'automatiser manuellement, et quand j'ai réalisé ce qu'il fallait faire, j'ai pris un peu de recul lorsque j'ai réalisé combien d'endroits je devais modifier pour le faire fonctionner. Merci mon dieu pour annuler la commande. J'ai une bibliothèque de classe C# standard incluse dans mon projet (diverses fonctions d'aide), que je suis en mesure de mettre à jour le numéro de version de mon processus de construction, donc j'utilise essentiellement cet assemblage pour la version complète application. Si quelqu'un veut savoir quelle version est dans un environnement, consultez le numéro de version de cet assembly.

Pas idéal, mais ça marche.

Answer 3

Nous l'avons fait avec succès sur notre projet - je vais voir si je peux obtenir le développeur de l'outil pour poster des détails ...

Answer 4

Developer- :)

Nous avons eu le même problème et nous avons fini par développer un petit utilitaire qui changerait le numéro de version dans tous les projets à savoir * .csproj (asssemblyinfo.cs), * .btproj en conséquence. En dehors de cela, il ouvrirait et modifierait les fichiers * .btp avec la nouvelle version des schémas. En bref, tout ce que vous avez à faire est de configurer cet utilitaire dans votre menu outils VS.net et l'exécuter.

Je suppose qu'il n'est pas très difficile de développer une telle utilité dans n'importe quelle lanière .net. Avertissement: N'oubliez pas d'enregistrer les fichiers après les mises à jour avec le même codage que celui utilisé à l'origine.

À la votre!

Answer 5

Ce problème se produit lorsque vous effectuez une intégration de construction aux dernières versions de vos composants dépendants en tant que références de fichiers (schémas aka ici). Gardez à l'esprit que la mise à niveau de la version d'assemblage doit toujours être effectuée manuellement, de cette façon, vous êtes toujours responsable des modifications apportées aux assemblages. Une solution possible pour résoudre le problème buildbreaks consiste à référencer une version spécifique d'une version de composant dépendant et non à la dernière version et à utiliser un lecteur subst et un script de copie pour obtenir les dernières versions de composant.

Par exemple:

SchemaA, la version de montage 1.0.0.0 PipelineA (avec PipelineComponent XMLValidator par exemple), la version de montage 1.0.0.0

PipelineA a une référence de fichier sur un lecteur Subst (dire lecteur R , qui correspond à un espace de travail D: \ MyComponents) et la version 1.0.0.0 de SchemaA comme suit:

R: \ SchemaA \ 1.0.0.0 \ SchemaA.dll. Le copy-script copie le buildoutput de SchemaA localement sur votre lecteur R. Lorsque le schéma A est mis à jour vers la version 1.1.0.0, vous n'avez aucun problème car vous utilisez toujours la version 1.0.0.0 et vous avez le choix d'utiliser la version 1.1.0.0 de votre schéma. Lorsque vous voulez mettre à niveau, vous devez modifier votre script de copie et remplacer la référence du fichier par R: \ SchemaA \ 1.1.0.0 \ SchemaA.dll.