Utilisation d'assemblages .Net versionnés

Question

Dans notre logiciel de traitement, nous passons d’une version d’un assemblage externe à une version plus récente. Bien que la tâche globale effectuée par l'assemblage soit la même, l'API est radicalement différente et aucune compatibilité en amont n'a été conservée. L'API est responsable de l'extraction des données de stations externes pouvant fonctionner avec une nouvelle ou une ancienne API correspondante (également sans compatibilité avec les versions antérieures). Nous n'avons aucun contrôle du logiciel dans l'assemblage externe ou sur les stations externes. L'assemblage externe n'est pas fortement signé et le module dans l'assemblage a le même nom pour les deux versions.

Au lieu de conserver deux versions de notre logiciel de traitement, nous aimerions le faire évoluer de manière dynamique et l’utiliser soit avec l’ancienne version, soit avec la nouvelle version de l’assemblage externe, en fonction de la station externe à contacter. Nous sommes en mesure de déterminer si un poste externe prend en charge la nouvelle version. Le choix de " version " peut être plus ou moins explicite.

La configuration est donc que nous avons un assembly externe ComLib.dll en deux versions. Pouvons-nous faire référence aux deux versions d’un même assemblage / projet et comment distinguer les deux assemblées lors de la détermination des types, etc.?

En supposant que ce qui précède ne puisse être effectué à partir d'un seul assemblage / projet, nous pourrions implémenter une version " adaptateur " spécifique à la version. assemblées, une pour chaque version de l’assemblage externe (je pense que nous avons déjà suffisamment d’interfaces et d’abstractions en place pour cela), mais y a-t-il des réserves à éviter, ou des paramètres spécifiques permettant d’éviter toute confusion de type / version à l’exécution (résolution de l’assemblage)? / chargement etc.)? Y a-t-il suffisamment de "côte à côte"? support dans le runtime .NET pour cette configuration?

MISE À JOUR: Une autre tournure à cette question est ajoutée juste pour rendre les choses plus intéressantes. Il semble que l'assemblage externe charge des assemblages supplémentaires et utilise des fichiers de configuration externes. Etant donné que les différentes versions nécessitent différents fichiers de configuration et différents assemblys supplémentaires, chaque version doit également charger les assemblys supplémentaires correspondant à leur version.

Il me semble que ce que nous souhaitons, c’est que les assemblys de chaque version soient chargés avec un " root " dans un dossier séparé contenant leur fichier de configuration et des assemblages supplémentaires. Est-ce même possible avec le résolveur / chargeur d'assemblages standard ou devrions-nous faire un peu de magie et peut-être charger des assemblys manuellement (dans AppDomains??) Distincts pour appliquer "& root". dossiers?

Answer 1

Un bon article sur les options pour cela peut être trouvé ici: http: // kevin-berridge. blogspot.com/2008/01/two-versions-of-same-shared-assembly.html

Answer 2

Vous dites que ce code est utilisé pour communiquer avec des stations externes. Pourquoi ne pas créer un service avec le code qui communique avec les stations externes? Ce service serait appelé depuis votre programme actuel.

Cela vous permettrait d’exécuter deux versions du service: une pour l’ancienne API et une pour la nouvelle. Chaque service serait dans son propre processus (ou peut-être AppDomain), donc pourrait charger les versions des assemblys qu'il aime. Lors du passage de votre programme principal d’une station à une autre, vous passeriez d’un service à un autre à mesure que la version de l’API change.

Cela présenterait l'avantage supplémentaire de vous isoler de votre fournisseur externe en créant une troisième version de l'API non compatible avec les deux versions précédentes.

Les performances de cette solution peuvent être assez élevées, car votre programme principal peut communiquer avec les services via des canaux nommés, voire un transport en mémoire. WCF peut basculer entre les transports (liaisons), dans la plupart des cas sans modification de votre code.

Answer 3

Vous pouvez signer les assemblages vous-même à l'aide de ILMerge , puis utilisez cette technique pour les référencer à partir du même projet.