Quelle est la bonne façon de gérer la version d'assemblage?

Donc, chaque assemblage doit avoir la même version qui est typiquement une combinaison de la version de déverrouillage, c'est-à-dire 3.4 + le numéro de construction qui représente le nombre de fois que la version a été compilée sur le serveur de construction. La révision est pertinente car elle démontre le nombre de constructions que vous avez créées pour cette version. Vous pouvez vraiment le faire de 2 façons. Le premier moyen serait que si vous planifiez une libération, c'est-à-dire 3.4, alors que vous commencez à travailler sur cette version, c'est votre numéro de version majeur et votre numéro de version mineure incréments avec la construction. Une autre façon de le faire consiste à contrôler étroitement les versions de construction en ce que lorsque vous êtes prêt à effectuer votre version à QA / Régression, vous définissez votre version majeure sur 3.4 et que vous laissez votre numéro de version mineure à 0. Vous gardez les choses étroitement contrôlées de cette façon. jusqu'à ce que vous libérez. De cette façon, vous pouvez contrôler votre numérotation de service de service via le numéro de version mineur. J'espère que cela aide.

La réponse dépend vraiment de ce que vous essayez d'accomplir avec les numéros de version de montage. Si vous faites un déploiement de ClickOnce et que vous souhaitez faire des téléchargements indépendants d'assemblys mis à jour, vous devrez avoir chaque assemblée indépendamment versionné - sinon, je pense qu'il est souvent agréable d'avoir des versions de montage correspondant au numéro de version du logiciel. Dans des scénarios plus complexes, vous pourriez avoir besoin d'une autre stratégie.

Un schéma que j'ai utilisé dans une entreprise antérieure a été Major.minor.revision.build - Donc, dans la version 1.0 du produit, la version de l'assemblage et la version de fichier d'assemblage sur chaque assemblage était de 1,0,0,1129 (par exemple). Cela a permis de correspondre à ce que les assemblages faisaient partie de la version du logiciel, jusqu'au numéro de construction. Nous avons accompli cela à l'aide d'une recherche de pré-compilation et remplacez dans chaque fichier montageInfo.cs pour remplacer un jeton avec les numéros de version fournis par notre processus de construction automatisé.

Nous tampons tous les assemblages de nos produits avec le même numéro de version en utilisant les étapes suivantes:

• liez tous les assemblages à un AssemblyInfocommon.cs contenant le Numéro de version Info: voir Voici Pour un exemple.

• générer le fichier associéInfocommon.cs dans le cadre de la construction Utilisation (dans notre cas) la tâche Nant ASMINFO, la commande de croisière .NET et le labelleur de révision SVN

  Dans notre cas, nous n'utilisons pas la version *. Toutes les versions déployées sont construites sur le serveur de construction. Nous ne nous inquiétons pas du numéro de version sur nos ordinateurs de bureau.

Je serais normalement convenir que tous les assemblages doivent avoir le même numéro de version; Cependant, je ferais une mise en garde à cela. Si l'une des assemblées est utilisée ailleurs en dehors de ce projet ou si elle est considérée comme propre son projet, il devrait avoir son propre numéro de version. Il devrait également être probablement déplacé de cette solution et de sa propre solution. La seule raison pour laquelle je mentionne, c'est que j'ai vu de nombreuses occasions où les gens ont une assemblée utilisée dans quelques autres endroits, mais principalement à un endroit et qu'ils essaient de garder la version droite. C'est une mauvaise idée de faire ça. Je pense que le principe de responsabilité unique s'applique également à la solution / au niveau du projet.

En ce qui concerne la numérotation, je suis d'accord avec Guy Starbuck (Major.minor.Revision.Build). C'est comme ça que je l'ai toujours fait et ça a toujours bien fonctionné.

Nous avons une grande application (centaines d'assemblages) avec des versions fréquentes (environ 1 par mois). Nous sommes allés pour le "donner à chaque assemblée la même version", mais c'est une source constante de maturité pour moi que les assemblages pour 1 version sont complètement incompatibles avec celles d'une autre, malgré le fait que les interfaces de ces aventions rarement (si jamais) changent.

Si tel est le cas pour vous, vous pourriez bénéficier des assemblages de versions séparément - chaque fois que vous mettez à jour votre montage ne vous souciez que d'incrémenter le numéro de version dans les cas où vous souhaitez réellement casser la liaison d'assemblage (par exemple si l'interface change, ou Les modifications sont autrement significatives que vous souhaitez empêcher une personne d'utiliser accidentellement la version précédente).