J'ai un complément VS qui utilise un formidateur binaire pour désérialiser un objet. Pour résoudre le type de cet objet, il appelle Assembly.load (ObjectTypefullName), mais il déclenche une exception car Assembly.Load ne peut pas trouver l'assemblage dans l'un des endroits où il recherche. L'assemblage donné est un frère à l'assemblage complémentaire, mais il semble que l'assemblage.Load () ne puisse pas le trouver là-bas.
Une solution possible serait de déterminer où l'assemblage.Load devrait rechercher des assemblages.
Que dois-je faire?
PS: J'essaie de ne pas mettre cette assemblée sur GAC car je devrais le mettre à jour à chaque fois que je recompile l'Assemblée.
3 Réponses :
Vous pouvez utiliser AppDomagneSetup.privatebinpath à ajouter Pistes de recherche privées supplémentaires. Ceci peut être récupéré via appdomain.setupinformation .
Une autre option consiste à abonner à AppDomain.assemblyResolve Afin de remplacer le comportement lorsqu'il ne trouve pas votre assemblée.
Merci de roseau. Certaines notes: même si l'AppDomain.AppendprivatePath est obsolète en faveur de AppDomelagnetup.privatebinpath, je ne pouvais utiliser que le premier. AppDomagneSetup.privatebinpath reste null après que je l'modifie. AppDomain.AppendPrivatePath me permet d'ajouter n'importe quel chemin qui est un enfant de l'AppDomain.Basedirectory, qui est dans de nombreux cas suffisant, pas dans le mien, car mon analyse de développement est Devenv. L'autre solution, AppDomain.assemblyResolve est assez bonne. Remarques: L'événement n'est appelé que lorsque .NET ne peut pas résoudre l'assemblage pour lui-même. Si tous les gestionnaires renvoient NULL, une exception est lancée
Si vous essayez simplement de déterminer où le chargeur de montage tente de charger votre DLL, je vous recommande d'activer les journaux de fusion. Cela vous permettra d'obtenir une sortie qui vous montrera chaque chemin qui a été vérifié pour la DLL correspondante.
Il y a un Article MSDN Sur la manière de configurer les journaux de fusion et un article utile par Suzanne Cook sur la façon de déboguer des échecs de chargement. Si vous allumez logfailure et que vous ne devez obtenir que la sortie des assemblages qui n'ont pas été chargés.
Très intéressant ces journaux de fusion, je lis l'article. Merci.
Voici une extraction de code montrant comment AssemblyResolve pourrait être utilisée pour résoudre votre assemblage (selon la réponse de Reed Copey): également, notez que la page MSDN pour AssemblyResolve stipule que: commençant par le .NET Framework
version 4, la
Résouseventargs.Requestingstingembly
propriété renvoie l'assemblage qui
demandé la charge de montage qui pourrait
ne pas être résolu ...
Ceci peut être utilisé si vous connaissez le lieu de votre assembly par rapport à celui de l'assemblage demandeur.
Hershi, merci +1. En fait, votre solution s'est avérée être celle que j'ai utilisée et j'ai fini par utiliser votre extrait. J'ai marqué la réponse de Reed tellement acceptée que c'est plus complète. Merci quand même.