L'assembly n'est pas disponible après le changement Web.config

Question

J'utilise un cadre personnalisé qui utilise la réflexion pour faire un GetTypeByName(string fullName) sur le nom de type complet qu'il obtient de la base de données, pour créer une instance de ce type et l'ajouter à la page, résultant en un type modulaire standard de chose.

GetTypeByName est une fonction d'utilité de la mienne qui itère simplement par Thread.GetDomain().GetAssemblies(), puis exécute un assembly.GetType(fullName) pour trouver le type approprié. Évidemment, ce résultat est mis en cache pour référence future et vitesse. Cependant, je rencontre des problèmes avec la mise à jour du fichier web.config (et dans certains cas plus effrayants si le pool d'applications est recyclé), il perd alors toute connaissance de certains assemblages, ce qui entraîne l'impossibilité de rendre une instance du type de module. Le débogage montre que l'assembly manquant n'existe pas littéralement dans la liste des assemblages de threads en cours. Pour contourner cela, j'ai ajouté une deuxième vérification qui est un peu sale mais récursif à travers les DLL du répertoire/bin/et vérifie que chacun existe dans la liste des assemblys. Si ce n'est pas le cas, il le charge en utilisant Assembly.Load et en corrigeant le problème de contexte grâce à 'Solving the Assembly Load Context Problem'. Cela fonctionnerait, mais il semble que (et je suis conscient que cela ne devrait pas être possible) certains projets ont toujours accès à l'assemblage manquant, par exemple mon projet Web réel plutôt que le cadre lui-même - et il se plaint que des références en double ont été ajoutées!

Quelqu'un a-t-il jamais entendu parler de ce genre de choses, ou a-t-il des idées sur la raison pour laquelle un assemblage disparaîtrait tout simplement d'un changement de configuration? A moins d'une solution, quelle est la solution la plus élégante pour obtenir tous les assemblages dans la poubelle à recharger? Il doit être tout en un "hit" afin que les visiteurs du site ne voient pas de différence autre qu'un petit retard, donc un fichier app_offline.htm est hors de question. Renommer par programme un DLL dans le chutier puis le renommer fonctionne, mais nécessite des autorisations "modify" pour le compte d'utilisateur IIS, qui est fou.

Merci pour les conseils que la communauté peut rassembler!

Answer 1

En règle générale, vous devriez éviter de vous fier aux assemblages actuellement chargés dans un domaine d'application, car cela se produit de manière dynamique. Au lieu de cela, appelez simplement System.Web.Compilation.BuildManager.GetType() au lieu de Type.GetType() ou Assembly.GetType(). Cela devrait juste faire la bonne chose pour vous, et ne pas être affecté par les cycles appdomain.

Answer 2

Je n'ai jamais entendu parler de ce problème auparavant. Je ne suis pas sûr si cela fonctionnera, comme je l'ai lu récemment tout en recherchant des solutions de contournement aux dépendances ODAC, mais en spécifiant le chemin de sondage pour les assemblys peut résoudre votre problème.

voir: http://msdn.microsoft.com/en-us/library/823z9h8w(VS.80).aspx

échantillon:

<configuration> 
    <runtime> 
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
     <probing privatePath="bin;bin2\subbin;bin3"/> 
     </assemblyBinding> 
    </runtime> 
</configuration> 

Answer 3

J'ai un problème similaire, lorsque je mets à jour 2-5 fichiers, web.config éther, d'autres fichiers, et asp.net doit recréer les fichiers en cours d'exécution, puis parfois ne trouve pas certaines classes/fonctions qui existent sur les fichiers dll, et mon système ne fonctionne pas - lancer des erreurs comme le vôtre.

Ma solution à cela est que je place le app_offline.htm à la racine, faire mes mises à jour, puis renommer/supprimer le app_offline.htm et mon système fonctionne très bien.

Je suis sûr que cela a quelque chose à voir avec les fichiers compilés mis en cache, mais je n'ai pas vraiment cherché quoi exactement.

[quelle est la solution la plus élégante pour obtenir toutes les assemblées dans le bac à rechargent]

Maintenant, quelle est la solution de contournement la plus élégante est d'appeler le HttpRuntime.UnloadAppDomain et faire réellement votre application à arrêter et recommence.

http://msdn.microsoft.com/en-us/library/system.web.httpruntime.unloadappdomain(VS.80).aspx

Je ne sais pas si cela résout votre problème, vous devez faire des tests.

probablement Global.asax faire quelque chose comme ça

void Application_Error(object sender, EventArgs e) 
{ 
    Exception ex = Server.GetLastError().GetBaseException(); 
    ...if ex is your error, and you get more than 2 ... 
    { 
    HttpRuntime.UnloadAppDomain(); 
    } 
} 

Answer 4

Comme vous le savez évidemment, there are many situations where the current appdomain is unloaded and reloaded. Après chaque rechargement, tous les assemblys sont déchargés et l'application entière commence à fonctionner "à partir de zéro".

Les assemblys sont chargés par défaut à la demande. C'est généralement le cas lorsque le JIT tombe sur une référence. En conséquence, un rechargement d'appdomain effacera les assemblages dans le domaine d'application et ils n'apparaîtront plus que lorsque le JIT les chargera.

En tant que solution, je reviendrai à utiliser la méthode statique Type.GetType() et fournir un nom qualifié d'assembly (par exemple un nom de type avec le nom de l'assembly inclus). C'est la même chose que le framework utilise lors du chargement des types spécifiés dans le fichier de configuration, et il s'assurera que l'assembly requis est recherché et chargé à la demande sans utiliser de trucs. Voir la section remarques de la méthode ci-dessus (le nom de la méthode au dessus du nom est un lien).

Cela nécessitera des mises à jour de votre base de données pour contenir des noms qualifiés d'assembly au lieu de noms de type «uniquement» complets. Cependant, il s'assure également que vous ne rencontrez pas de collisions de noms lorsque deux assemblages fournissent un type différent avec le même nom, donc c'est une bonne idée de toute façon je pense.

Answer 5

Je voudrais essayer de créer une classe de base à partir de laquelle assemblage, ce qui est intéressant pour vous sans réflexion sur Application Start pour s'assurer qu'il est chargé. E.g.

var temp = new BaseModuleBuilder(); 

Cela ne semble pas intelligent, mais il est très simple et asp.net devrait faire tout pour vous. Dans le cas où votre liste est trop dynamique, il pourrait être quelque chose comme

var temp = Activator.CreateInstance(Type.GetType("BaseModuleBuilder, Modules.dll")); 

Assurez-vous de toujours spécifier DLL lorsque vous travaillez avec des classes dynacmically chargées.