11
votes

MEF Chargement des plugins à partir d'un dossier partagé réseau

Déchirer mes cheveux en essayant de déterminer pourquoi j'ai ce problème, j'espère que quelqu'un peut aider.

J'ai un programme qui utilise Mef pour charger des plugins. J'aimerais que le client et le serveur font partie du système puisse utiliser le même magasin Plugin qui sera situé sur le serveur. P>

Mon problème est que lorsque je réglais l'emplacement du plug-in sur " c: \ users \ administrateur \ dektop \ clientPlugins code>" Le plugin est bien chargé. Si je change l'emplacement vers " \\ xrp-server \ users \ administrateur \ dektop \ clientPlugins code>" Le plugin n'est pas chargé. P>

lorsque j'entre " \\ xrp-server \ users \ administrateur \ dektop \ clientsClugins code>" dans l'explorateur Windows L'emplacement est trouvé et la dll plugin est là. P>

S'il vous plaît que quelqu'un pourrait vous aider. p>

laissez-moi savoir si vous avez besoin d'informations plus d'informations. P>

Selon une suggestion, j'ai essayé de modifier la configuration pour inclure les éléments suivants, mais cela n'a pas résolu les problèmes ... P>

  <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <runtime>
        <loadFromRemoteSources enabled="true"/>
      </runtime>


0 commentaires

4 Réponses :


0
votes

essayez d'utiliser system.io.path.pathseparator au lieu de \?

ou peut être récupéré le fichier à l'emplacement du client en premier?

Je ne suis pas assez sûr d'eux, mais je vais essayer.


4 commentaires

Merci je vais essayer le séparateur de chemin. Une tâche future consiste à diffuser le plugin à partir du serveur via WCF si le client n'a pas accès à l'emplacement partagé. Je veux obtenir l'emplacement partagé d'abord travailler et je veux comprendre pourquoi ce n'est pas :)


Une autre chose est que, quand je pense à elle: utiliser "Fichier: //"?


J'ai vérifié que je fournis le chemin au format, le C # peut lire. int fcount = Directory.getFiles ("\\\\ xrp-serveur \\ utilisateurs \\ Administrator \\ de Sktop \\ ClientPlugins", ". ", on se phardoption.topdirectoryonly) .length; Console.writeine ​​(fcount); Ce retour 1 qui est la dll plugin


Donc, la backslashes est la réponse?



8
votes

Les stratégies de sécurité permettront généralement de charger le code à distance (qui étant des assemblages sur un emplacement externe).

Vous pouvez essayer la modification de configuration suivante: xxx

l'autre La chose à conscience est que lorsque vous copiez des fichiers à partir des emplacements réseau, ils auront généralement une zone spécifiée dans leur flux de données alternatif. Dans Explorer, cela peut être supprimé en utilisant la commande "Débloquer" lors de la visualisation des propriétés d'un fichier.

Alternativement, vous pouvez supprimer de manière programmative la zone du flux de données alternatif, comme indiqué ici sur le blog de Mike Hadlow .


1 commentaires

Quand j'ai vu cela, mes yeux sont allumés comme je pensais que cela fonctionnerait. Cela ne ressemble pas à cela :( J'ai placé cela dans la configuration et il ne se charge toujours pas lorsque vous utilisez le chemin '\\ XRP-Server \ users \ Administrator \ Desktop \ ClientPlugins' ClientPlugins '. Toute autre idée?



3
votes

J'ai couru dans ce problème hier et réduit le problème jusqu'à la manière dont le MEF charge des assemblages. Lorsque vous créez un répertoireCatalog, il crée une collection de Catégorie AssemblyCatalogues. Chaque AssemblyCatalog utilise un: xxx

l'appel à assembly.load jette une exception de bac à sable (pour une raison, je ne peux pas encore expliquer) et donc aucune pièce n'a été trouvée. Puisqu'il attrape silencieusement l'erreur.

La chose amusante est que Calling assembly.loadfrom () Pour renvoyer un assemblage fonctionne (non une exception est lancée). Combinez cela avec le constructeur surchargé de AssemblyCatalog qui prend un assemblage comme entrée et vous avez une solution de contournement!

donc au lieu d'utiliser un DirectoryCatalog , je répertorie toutes les DLL dans le chemin et crée itérativement un AssemblyCatalog et l'ajoutez à mon CompositionContainer .

Remarque: J'utilise le drapeau LoadfromRemotesources = "True" dans mon app.config et il est requis, sinon il se bloque toujours.

espère que cela aide


4 commentaires

Je suis en train de tenter cela et je suis avec vous jusqu'à ce que vous ajoutez l'assemblageCatalog à la compositionContainer. Je ne peux pas voir une méthode d'ajout sur la compositionContainer. Pourriez-vous expliquer ce bit un peu plus s'il vous plaît?


Son ok j'ai travaillé, vous avez besoin de créer un agrégatecatalogue, puis ajoutez votre assembléeCataglogogues, puis ajoutez votre agrégatecatalogue à la compositionContainer.


S'il vous plaît laissez-moi savoir si vous découvrez pourquoi cela fonctionne et la méthode standard ne :) I Daesay Microsoft serait intéressée à connaître ASWELL :) Merci encore pour la réponse :)


J'ai regardé par le réflecteur mais je n'ai pas pu trouver la raison pour laquelle. Je suppose que cela a à voir avec les différences de contexte entre la charge et le chargement de Loadfrom (voir ici ). Depuis ma dernière réponse, j'ai également constaté que Chargefrom peut être dangereux et j'ai rencontré ce problème ici : Chargement de deux fois la même DLL est possible avec chargement et entraîne des comportements étranges. Vous devez être rigoureux si vous allez utiliser LoadFrom :)



2
votes

Juste pour clarifier les travaux de réponse de SEBD.

Heres le code final que j'ai utilisé. xxx


0 commentaires