Y at-il de bonnes raisons de laisser AssemblyVersion correspondance et AssemblyFileVersion?

Question

a un Gendarme AvoidAssemblyVersionMismatchRule avec la description suivante:

  

Cette règle vérifie que les matches [AssemblyVersion] [AssemblyFileVersion] lorsque les deux sont présents à l'intérieur d'un assemblage. Ayant des numéros de version dans les deux attributs peut être source de confusion une fois que l'application est déployée.

Par exemple, cette règle avertirait sur System.dll de Microsoft qui a les attributs suivants:

[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.50727.3053")]

Je suis en désaccord avec la règle de Gendarme. Après il serait impossible d'utiliser un système de versioning similaire à celui utilisé par Microsoft, qui est

• Mise à jour AssemblyFileVersion sur chaque build,
• Changement AssemblyVersion uniquement sur l'interface publique ou autre modification importante,
• Assurez-vous que AssemblyVersion et AssemblyFileVersion partagent un préfixe commun,

et je pense que ce système de versioning est la raison de la conception pourquoi il a été rendu possible de faire la différence entre AssemblyVersion et AssemblyFileVersion en premier lieu.

Je ne peux pas trouver une raison pour laquelle les deux attributs forçant l'assemblage à égal est une bonne pratique, mais peut-être vous le pouvez! Je serais intéressé par vos opinions.

En effet, s'il n'y a aucune raison, je vais bientôt les développeurs suggère Gendarme de changer la règle

  

Cette règle vérifie que le [AssemblyVersion] [AssemblyFileVersion] une commune, non préfixe vide lorsque les deux sont présents à l'intérieur d'un assemblage.

Answer 1

D'accord, si elles doivent correspondre alors il n'y aurait pas besoin d'être deux attributs différents pour commencer! Mais comme la règle dit:. Il pourrait être source de confusion

AssemblyVersion est plus comme « La version de votre application entière », tandis que FileVersion est la version d'un fichier individuel. Si votre application dispose de plusieurs ensembles qui ont des cycles de mise à jour pour une raison quelconque (par exemple, Plugins qui sont mis à jour séparément, mais qui nécessitent une version majeure spécifique de l'application principale), alors vous pourriez donner à chacun un autre FileVersion mais ont une AssemblyVersion commune.

En outre, parfois, il est vraiment pratique de mettre à jour le AssemblyVersion (par exemple, SharePoint Workflows et les composants WebPart sont un PITA mettre à jour parce qu'ils attendent un AssemblyVersion spécifié), donc il le FileVersion est souvent utilisé comme la version réelle.

Answer 2

D'accord, cela est une règle stupide. Vous ne pouvez déployer une mise à jour de bug fix drop-in pour une forte assembly nommé lorsque vous suivez. Il y a par ailleurs quelques raisons de ne pas les faire la même chose si vous avez réellement changer la [AssemblyVersion]. Peut-être que vous n'êtes pas censé utiliser cet outil lorsque vous corriger des bugs. Ironique.

Answer 3

Je pense que la règle est logique dans de nombreux scénarios, puisque le .NET Framework considère essentiellement deux ensembles avec le même AssemblyVersion interchangeables.

Ainsi, par exemple, une ancienne version est dans le cache de téléchargement ne sera pas automatiquement remplacé par une nouvelle version différente que dans AssemblyFileVersion.

Cela peut être source de confusion pour le développeur moyen, d'où la règle.

Bien sûr, si vous savez ce que vous faites et comprendre les compromis, vous pouvez ignorer la règle.