Noms et versions des assemblées

Question

Qu'est-ce qui est considéré comme la meilleure pratique en matière d'assemblages et de versions?

J'aimerais pouvoir référencer plusieurs versions de la même bibliothèque. La solution contient plusieurs projets qui dépendent de différentes versions d'une bibliothèque commonutils.dll que nous construisons nous-mêmes.

Toutes les dépendances étant copiées dans les répertoires bin / debug ou bin / release, une seule copie de commonutils.dll peut exister, et ce, même si chacun des fichiers DLL porte un numéro de version d'assembly différent.

Devrais-je inclure des numéros de version dans le nom de l'assembly pour pouvoir référencer plusieurs versions d'une bibliothèque ou existe-t-il un autre moyen?

Answer 1

Voici ce que j'ai vécu -

Cela dépend de l'utilisation que vous comptez faire des fichiers DLL. Je les classe en deux groupes principaux:

1. Assemblées sans issue. Il s’agit de fichiers EXE et de fichiers DLL sur lesquels vous n’avez vraiment pas l'intention de faire référence. Nommez-les simplement et assurez-vous que les numéros de version que vous avez publiés ont été étiquetés dans le contrôle de la source, afin que vous puissiez les restaurer à tout moment.

2. Assemblys référencés. Nommez-les de manière à ce que vous puissiez avoir plusieurs versions référencées par d'autres assemblys. Utilisez le nom complet pour les référencer (Assembly.Load). Conservez une copie de la version la plus récente de celle-ci dans un endroit où d'autres codes peuvent s'y référer.

Ensuite, vous avez le choix de copier en local ou non vos références. En gros, le compromis se résume à: voulez-vous prendre en charge les correctifs / mises à niveau de vos références? L’obtention de nouvelles fonctionnalités peut présenter un intérêt positif, mais d’autre part, des changements radicaux pourraient avoir lieu. Je pense que la décision ici devrait être prise au cas par cas.

Lors du développement dans Visual Studio, vous utiliserez par défaut la dernière version à compiler , mais une fois compilé, l'assembly de référencement nécessitera la version spécifique avec laquelle il a été compilé.

Votre dernière décision est de copier Local ou non. En gros, si vous avez déjà un mécanisme en place pour déployer l'assembly référencé, définissez-le sur false.

Si vous envisagez de mettre en place un système de gestion des versions volumineux, vous devrez probablement y réfléchir davantage. Pour moi (petit magasin - deux personnes), cela fonctionne bien. Nous savons ce qui se passe et ne nous sentons pas empêchés d’avoir le devoir de faire les choses d’une manière qui n’a pas de sens.

Une fois que vous avez atteint le runtime, votre assemblage.Chargez ce que vous voulez dans le domaine d'application . Ensuite, vous pouvez utiliser Assembly.GetType pour atteindre le type souhaité. Si un type est présent dans plusieurs assemblys chargés (par exemple, dans plusieurs versions du même projet), vous pouvez obtenir un AmbiguousMatchException exception. Pour résoudre ce problème, vous devez extraire le type d'une instance d'une variable d'assembly, et non la méthode statique Assembly.GetType.

Answer 2

Les assemblys peuvent coexister dans le GAC (Global Assembly Cache) même s'ils portent le même nom, car leur version est différente. Voici comment fonctionnent les assemblys fournis .NET Framework. Une condition à remplir pour qu'un assemblage puisse être enregistré GAC doit être signée.

Ajouter des numéros de version au nom de Assembly va à l’encontre de tout l’objet de l’écosystème d’assemblage et est fastidieux à mon humble avis. Pour savoir quelle version d'un assemblage donné il suffit d'ouvrir la fenêtre Propriétés et de vérifier la version.

Answer 3

Donner des noms différents à différentes versions d'assemblages est le moyen le plus simple et fonctionne certainement.

Si votre assembly (commonutils.dll) porte un nom fort (c'est-à-dire signé), vous pouvez envisager de l'installer dans le GAC (Global Assembly Cache). Vous pouvez installer différentes versions du même assembly côte à côte dans le GAC), par conséquent, l'application appelante obtient automatiquement la version appropriée à partir de là, car les types .NET incluent des informations sur la version de l'assembly.

Dans votre projet VS, vous référencez la version correcte de la bibliothèque, mais vous ne la déployez pas dans le dossier de l'application. vous l'installez plutôt dans le GAC (lors de l'installation de l'application).