Nous avons actuellement un débat interne passionné sur la question de savoir si le nom de l'assembly .NET doit inclure le numéro de version du code (par exemple CodeName02.exe ou CompanyName.CodeName02.dll). Est-ce que quelqu'un sait d'une source faisant autorité, comme Microsoft, qui fournit des conseils sur cette question?Les noms d'assembly .NET doivent-ils inclure un numéro de version?
Ceci est à quoi sert le fichier Properties/AssemblyInfo.cs.
Il existe deux versions dans ce fichier, la version du fichier et la version de montage:
[assembly: AssemblyVersion("1.1.0.256"]
[assembly: AssemblyFileVersion("1.1.0.256")]
Une fois ces sont définis, vous pouvez les utiliser pour suivre les versions de binaires vous. Il est facilement visible dans l'explorateur avec les propriétés clic droit->.
Aucun des noms dll ou exe inclus dans les applications Microsoft (et OS) n'utilise cette convention.
D'autres systèmes utiliseront ces numéros pour résoudre les dépendances et vérifier la version. Par exemple, le système MSI mettra à jour les fichiers binaires en fonction des propriétés de la version.
Je ne connais rien d'autorité, mais il me semble que l'utilisation d'un nom cohérent simplifierait tout, du processus d'installation des scripts à la documentation. Étant donné que l'on peut stocker la version en tant que métadonnées sur le fichier, je ne sais pas pourquoi il serait nécessaire dans le nom de fichier. Pourquoi vous préparer aux tracas d'avoir à tenir compte des fichiers nommés différemment?
Les informations de version peuvent être contenus dans le fichier AssemblyInfo et peut ensuite être interrogé par la réflexion, etc.
Certains fournisseurs comprennent le numéro de version dans le nom pour le rendre plus facile de voir en un coup d'oeil ce qu'il est. Les noms Microsoft DLL ne contiennent pas un numéro de version dans le répertoire du framework.
Il suffit de regarder le framework .NET ou tout autre produit Microsoft. mettre un numéro de version dans le nom de l'assembly semble être une mauvaise idée.
Il existe une place pour cela (et d'autres informations) dans la section des métadonnées de l'assembly. (AssemblyInfo.cs)
Ces informations peuvent être affichées dans l'Explorateur Windows (boîte de dialogue des propriétés, barre d'état, info-bulle - elles affichent toutes ces informations).
Depuis la version peut être définie comme une propriété n'est pas ce semi-redondant?
Je voudrais aussi aller sur une branche et suggère MS ne dispose pas d'un standard donné un rapide coup d'oeil à leurs noms de DLL: user32.dll, tcpmon.dll, winsock.dll, etc.
Ce ne sont pas des composants .NET - ils sont natifs win32 et sont soumis à "DLL enfer". Dans .NET, le gac est utilisé pour fournir des versions et permet aux DLL suivantes d'avoir le même nom physique. – x0n
Je ne suis pas sûr que citer 20 ans d'archéologie logicielle est terriblement pertinent! Les noms de cette époque devaient être de 8,3, ce qui tend à dominer plutôt le débat. –
Framework Design Guidelines par Krzysztof Cwalina et Brad Abrams de Microsoft suggère de nommer l'ensemble comme
<Company>.<Component>.dll
Je soutiens encore cette (sans utiliser la version #) parce que le GAC et les propriétés du fichier dll affiche la version.
Et, comme indiqué, la version d'assemblage est accessible via les propriétés Assembly dans AssemblyInfo.cs –
Je pense que l'idée principale de mettre un numéro de version dans le nom de fichier d'une DLL est DLL Hell, où ayant plusieurs versions de la DLL, tous avec le même nom a causé des problèmes (ie quelle version réelle de une DLL avez-vous et a-t-elle les fonctions requises, etc).Le .NET Framework gère des dépendances complètement différentes par rapport aux fichiers DLL C/C++ qui sont plus traditionnels, il est possible d'avoir plusieurs versions d'une bibliothèque dans le GAC, principalement parce que le GAC est un dossier «faux» qui liens vers d'autres fichiers sur le système de fichiers, en plus d'être en mesure d'avoir les assemblys inclus avec votre installation exécutable (même dossier de déploiement, etc).
Je sais que DevExpress website utilise des indicateurs de version dans le cadre de leurs noms d'assembly tels que XtraEditors8.2.dll. Je suppose que la raison est que vous voulez pouvoir avoir plusieurs versions de l'assembly situées dans le même répertoire. Par exemple, nous avons environ 15 smartclients qui sont distribués dans le même shell/client. Chaque smartclient peut avoir une version différente des contrôles DevExpress et, par conséquent, nous devons pouvoir avoir XtraEditors7.1.dll et XtraEditors8.2 dans le même répertoire. Je dirais que si vous avez des bibliothèques communes qui sont des dépendances de modules réutilisables et peuvent exister dans plusieurs versions 1.0, 1.1, 1.2 etc. alors il serait un argument valide que les numéros de version pourraient être inclus dans le nom pour éviter collisions. Étant donné que les bibliothèques communes ne vivent pas dans le GAC.
Je le fais exactement pour cette raison que j'ai partagé DLL sur un lecteur réseau utilisé par plusieurs programmes et personnes. S'il y a un problème dans la disponibilité, je peux mettre à niveau une DLL et un programme en fonction de cela sans affecter les utilisateurs. – PeteT
Microsoft utilisait un suffixe de 32 pour désigner les versions de DLL 32 bits afin que ces DLL puissent coexister avec les fichiers DLL 16 bits existants.
Comment augmenter le nombre de build automatiquement après chaque build? Ou dois-je manuellement ouvrir ce fichier et modifier le maj, min, numéro de construction à chaque fois? –
utilisez et * plutôt qu'un nombre et la construction augmentera automatiquement la valeur. 1.1. * –
Vous pouvez également définir AssemblyInformationalVersion qui se termine par le champ VERSIONINFO "ProductVersion". –