Chargement dynamique d'assemblages et de leurs dépendances à l'aide du déploiement XCOPY

Question

J'ai un chargeur d'application qui charge dynamiquement les applications. Une application est un assembly avec toutes ses dépendances dans un seul dossier. Utilisation du déploiement XCOPY Je peux ajouter/supprimer des applications en copiant/supprimant un dossier. Pour faciliter la liaison d'assemblage .NET standard, je copie les dossiers d'application sous la corbeille du chargeur. Je place le privatePath de sondage dans le fichier de configuration et tout fonctionne comme un charme.

Les applications utilisent un cadre, c'est-à-dire des assemblys partagés en tant que dépendants.

Maintenant, j'ai une exigence qui stipule que chaque application doit être en mesure d'utiliser sa propre version de l'infrastructure.

Cela fonctionne parfaitement lorsque j'installe les versions du framework dans le GAC, et les différentes versions de l'assembly sont chargées dans l'AppDomain par défaut.

Maintenant, je veux revenir à ma solution XCOPY et copier les versions de framework correctes dans leurs dossiers d'application correspondants et les pauses de solution.

La première application référençant son framework fonctionne très bien, la seconde se plaint de ne pas trouver l'ensemble et les manifestes ne correspondent pas. C'est comme si le chargeur .NET arrêtait de tester après une première correspondance de l'assembly avec un dossier dans "privatePath" et ne regardait plus rien.

Des idées sur la façon d'avoir le même comportement que lors de l'utilisation du GAC? Autre chose que je pourrais spécifier dans config, codeBase? (pas de chemins de fichiers absolus s'il vous plaît).

kr, Michel

Answer 1

Selon this article sur les assemblées:

Vous devez également vous rappeler que le CLR regarde à travers une séquence prédéterminée des répertoires pendant le sondage. Etant donné un valeur privatePath de MyAssemblies, le CLR sonde maintenant un ensemble appelé MyLibrary dans l'ordre suivant:

C:/Apps/MyLibrary.DLL 
C:/Apps/MyLibrary/MyLibrary.DLL 
C:/Apps/MyAssemblies/MyLibrary.DLL 
C:/Apps/MyAssemblies/MyLibrary/MyLibrary.DLL 
C:/Apps/MyLibrary.EXE 
C:/Apps/MyLibrary/MyLibrary.EXE 
C:/Apps/MyAssemblies/MyLibrary.EXE 
C:/Apps/MyAssemblies/MyLibrary/MyLibrary.EXE 

La séquence des chemins de fichier dans lequel les sondes CLR pour un fichier d'assemblage est important car le processus de palpage s'arrête une fois que le CLR localise un fichier d'assemblage avec le nom de fichier correct. Si déployer une application avec une version de MyLibrary.dll dans le répertoire ApplicationBase et une seconde version dans le sous-répertoire MyAssemblies, quel fichier DLL la charge CLR? Vous devriez voir que le CLR va charger la DLL dans le répertoire ApplicationBase parce que est toujours le premier répertoire recherché par le CLR au cours du processus de sondage.

Mise à jour:

Vérifiez this poste. Il traite plus ou moins du même problème que vous.

Answer 2

Vous aurez plus de chance si vous utilisez Assembly.LoadFrom pour charger tous les assemblages que vous trouvez dans ces dossiers.

Cela modifie le comportement de sondage et permet à l'environnement d'exécution de rechercher localement à partir de l'endroit où l'assembly a été chargé à l'origine afin de trouver ses références. Cependant, vous obtiendrez le partage de la version de la structure au niveau de l'assemblage.

C'est:

• App 'a' des charges, ce qui v1.02-cadre à charger.
• L'application 'b' se charge, entraînant le chargement de Framework v1.01.
• L'application 'c' charge, liée à Framework v1.02, et réutilise simplement le code qui a été chargé après le chargement de l'application 'a'.

cela dit - cette solution pourrait être inutile si vous ne chargez pas explicitement les assemblages.

Dans ce cas - j'irais avec la solution dans la réponse mentionnée par Yannick M. - accrocher dans l'événement AssemblyResolve; stocker un état statique lorsque vous commencez à charger une application afin que votre gestionnaire d'événements sache quelle application est en cours de chargement; et si un assemblage échoue à résoudre, vous pouvez regarder cet état pour déterminer où il devrait chercher et charger l'assembly à partir de là.