Impossible de diffuser un proxy transparent pour taper depuis AppDomain

Je suis en train de créer un objet dans un domaine d'application:

var type = typeof (CompiledTemplate);
var obj = (CompiledTemplate) domain.CreateInstanceAndUnwrap (
    type.Assembly.FullName, type.FullName);

Cependant, je reçois toujours le message d'erreur suivant:

Impossible de cast transparent proxy de type " Mono.TextTemplating.CompiledTemplate'.

Je suis en cours d'exécution sur .NET 4.0, pas Mono, en dépit de ce que l'espace de nom pourrait le suggérer 🙂

Autant que je sache, cette erreur se produit lorsque .NET pense que le Type de & Assemblée ne correspondent pas exactement dans les deux domaines. Toutefois, lorsque le débogage, le Nom et l'Emplacement sont identiques. Seule l'Assemblée.Le code de la propriété qui varie dans l'AppDomain enfant son extension est en majuscule de "DLL" pour une raison quelconque.

J'ai essayé d'ajouter un AssemblyResolve gestionnaire pour le domaine d'application, qui utilise de l'Assemblée.LoadFrom pour charger le fichier explicitement, mais le Code de l'extension est toujours en majuscule. Depuis la première assemblée a également été chargé avec de l'Assemblée.LoadFrom (via Mono.Addins), la différence entre la base de valeurs semble très étrange.

Toutes les suggestions de correction ou de travail autour de ce problème?

source d'informationauteur Mikayla Hutchinson

  1. 5

    Pourriez-vous avoir un problème avec l'assemblée de la charge contextes?
    (voir, par exemple,ici)
    Vous avez un type qui est clairement dans la charge de contexte (parce que vous êtes à l'aide de typeof(CompiledTemplate)), mais vous êtes en train de dire que le type dans le secondaire AD est chargé dans la charge de contexte...

    Avez-vous vérifier avec fuslogvw pour déterminer exactement ce que les assemblages sont en cours de chargement? Le fuslog trace également vous dire si les assemblages sont en train d'être chargés dans des contextes différents.

  2. 1

    Un deuxième exemplaire de l'assemblée est, en effet, être chargé en mémoire tel qu'il est.

    Une instance d'un type à l'exécution est spécifique à la instance de l'assemblée chargé - de sorte que même si le même fichier DLL qui est chargée dans un deuxième temps, les types ne sont pas considérés comme match.

    C'est un problème typique lorsque "DLLHell" est prolongé dans le "GACAndDLLHell". "GACONLYHeaven" est un meilleur endroit ... :).

    Que les noms de fichier sont légèrement différents (l' .DLL d'extension a un autre cas) implique que la même DLL est chargé à partir de deux endroits (ce qui est: le GAC est pas sensible à la casse et/ou des minuscules dans les noms de fichiers IIRC).

    Une classe abstraite ou, de préférence, une interface est ce que vous avez besoin ici.

    Si vous ne pouvez pas apporter des modifications à la base de code, je voudrais, tout d'abord, assurez-vous que la DLL existe en 1 seule place sur le disque dur (ou 0 places sur le disque s'il est chargé à partir du GAC). Une copie de la DLL qui contient le type: "CompiledTemplate" dans votre application /bin serait une véritable coupable ...?

    Est ce nouveau code ou code existant qui est maintenant échoue pour une raison quelconque?

  3. 0

    Peut-être vous pouvez utiliser le dynamique mot-clé au lieu d'un moulage d'un type spécifique:

    var type = typeof (CompiledTemplate);
dynamic obj = domain.CreateInstanceAndUnwrap (
    type.Assembly.FullName, type.FullName);

    Qui peut au moins vous donner une solution de contournement du problème. Bien sûr, les inconvénients potentiels sera de ne pas avoir le temps de compilation du contrôle et/ou un ralentissement des performances. Toutefois, ceux-ci pourraient être négligeable à des arbitrages en fonction de votre situation.