Question

Nous avons actuellement un débat interne houleux 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). Quelqu'un connaît-il une source faisant autorité, telle que Microsoft, qui fournit des conseils sur ce problème?

Était-ce utile?

La solution

C’est à cela que sert le fichier Properties / AssemblyInfo.cs.

Ce fichier contient deux versions, la version du fichier et la version de l'assembly:

[assembly: AssemblyVersion("1.1.0.256"]
[assembly: AssemblyFileVersion("1.1.0.256")]

Une fois ceux-ci définis, vous pouvez les utiliser pour suivre les versions de vos fichiers binaires. Il est facilement visible dans l'explorateur avec les propriétés du clic droit.

Aucun des noms de DLL ou d'exe inclus dans les applications (et le système d'exploitation) de Microsoft 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.

Autres conseils

Consignes de création de structure par Krzysztof Cwalina et Brad Abrams de Microsoft suggère de nommer les assemblages comme

<Company>.<Component>.dll

Je prends également en charge cette fonctionnalité (PAS avec la version #) car les propriétés des fichiers GAC et dll indiqueront la version.

Je ne suis au courant d'aucun document faisant autorité, mais il me semblerait 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 sous forme de métadonnées dans le fichier, je ne sais pas pourquoi elle serait nécessaire dans le nom du fichier. Pourquoi vous installer sans avoir à prendre en compte des fichiers portant un nom différent?

Il suffit d’examiner le framework .NET ou tout autre produit Microsoft. mettre un numéro de version dans le nom de l'assembly semble une mauvaise idée.

Il y a une place pour cela (et d'autres informations) dans la section des métadonnées de l'assemblage. (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).

Je sais que DevExpress site Web utilise des indicateurs de version dans le cadre de noms d'assemblages tels que XtraEditors8.2.dll. Je suppose que la raison en 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 clients intelligents qui sont distribués dans le même shell / client. Chaque client intelligent peut avoir une version différente des contrôles DevExpress. Par conséquent, nous devons pouvoir disposer de XtraEditors7.1.dll et de XtraEditors8.2 existants 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., l'argument suivant serait que des numéros de version pourraient être inclus dans le nom pour éviter les conflits . Étant donné que les bibliothèques communes ne vivent pas dans le GAC.

Je pense que l'idée principale de mettre un numéro de version dans le nom de fichier d'une DLL provient de DLL Hell , où plusieurs versions de la DLL, toutes portant le même nom, posaient problème (c'est-à-dire quelle version réelle d’une DLL avez-vous et at-elle les fonctions requises, etc.).

Le .NET Framework gère les dépendances complètement différentes des fichiers DLL C / C ++ plus traditionnels, il est possible d’avoir plusieurs versions d’une bibliothèque dans le GAC, principalement parce que le GAC est un "faux" dossier qui relie aux autres fichiers du système de fichiers, en plus de pouvoir inclure les assemblys dans votre installation exécutable (déploiement du même dossier, etc.).

Les informations de version peuvent être contenues dans le fichier assemblyInfo et peuvent ensuite être interrogées par réflexion, etc.

Certains fournisseurs incluent le numéro de version dans le nom pour faciliter la visualisation de ce qu’il en est. Les noms Microsoft dll ne contiennent pas de numéro de version dans le répertoire framework.

Etant donné que la version peut être définie en tant que propriété, cette version n'est-elle pas redondante?

Je voudrais aussi aller un peu plus loin et suggérer à MS de ne pas avoir de norme en donnant un rapide aperçu de leurs noms de DLL: user32.dll, tcpmon.dll, winsock.dll, etc.

Microsoft a utilisé 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.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top