La plupart des applications utilisent un timestamp pour générer le build et la révision (du type nombre de jour depuis l'an 2000 et nombre de seconde depuis minuit divisé par 2) comme le propose par défaut le framework Microsoft pour peu qu'on utilise une étoile comme ceci [x.y.*], x étant le numéro de version majeur et y le mineur. Sans suspense je vous dévoile une manière plus fun, qui ne plaira certainement pas à votre chef de projet… Tout simplement [x.y.MMd.HHmm] soit [x.y.(numéro_du_mois)(numéro_du_jour).(heure)(minute)], comme par exemple [x.y.0215.0105] pour le 15 février à 1h05. Voyons ensemble comment automatiser la chose, pour ne pas faillir à notre réputation de développeur feignant…
Comme on peut l'apprendre sur ce CodeProject signé Bruno Tagliapietra en 2013, on peut automatiquement incrémenter les compteurs de versions de l'Assembly avec le langage de template T4. J'ai aussi vu des variantes de 2014 fournies par ce billet ou encore celui là qui utilise un DateTime. Il en fallait pas plus pour faire germer en moi l'idée diaboliquement tordue de joindre l'utile à l'agréable.
Ma méthode permet en effet en un coup d’œil de savoir à quelle date la version a été faite, toutefois en faisant fi de l'année. La raison ? Une limitation de 16 bits pour chacun des 4 nombres (soit 65535) : il faut donc faire un choix et donc on se concentrera dans un premier temps sur les informations les moins évidentes à trouver par soi-même. Effectivement, si la manière de développer votre projet le permet, l'année peut être déterminée par déduction (en se disant bon, ce build date de janvier par exemple, il est en version 2.5 cela doit donc être telle année…) ou bien allé pour aller encore plus loin dans le délire, pour que le build/révision ne soit pas incrémental que sur la l'année en cours, il serait peut-être judicieux de changer de numéro de version mineur chaque année… voire même d'y mettre les deux derniers chiffres de l'année comme ceci : [1.115.0214.0105] pour une version 1.1 buildée en 2015.
Alors par delà cette histoire de date tirée par les cheveux , j'ai au moins fait un truc sympa et utile que les autres développeurs susmentionnés n'ont pas fait ! J'ai catché les exceptions et foutu celles-ci en commentaire dans le fichier de sortie AssemblyVersion.cs. Même si ce n'est généralement utile qu'en période de développement, cela ne mange pas de pain et m'a d'ailleurs évité pas mal de tâtonnement, car il n'y a malheureusement pas d'analyseur syntaxique pour le C# contenu dans le T4. Comme quoi ce bousin là c'est encore pas le Pérou, et en plus ça existe depuis des plombes dans Visual Studio (oui je sais on peut faire son code dans un *.cs puis le transvaser dans son *.tt mais oui, vous devez le savoir maintenant, je suis un emmerdeur…).
Pour ceux qui penserait que l'AssemblyFileVersion n'est pas important car je ne l'ai pas touché dans mon snippet (pour l'instant je ne fais pas de déploiement), je les invite à lire ceci.
En gros pour éviter d'avoir des soucis de versions lors de la résolution des dépendances, on peut garder constant l'AssemblyVersion, et utiliser l'AssemblyFileVersion pour donner la version effective de l'assembly qui correspond à un correctif par exemple. Microsoft utilise cette technique : System.dll (.NET 2.0) est en 2.0.0.0, alors que l'AssemblyFileVersion (visible dans les propriétés du fichier sous windows) est par exemple 2.0.50727.4927.