je suis tombé sur une exception Remoting:
« Ce proxy d'accès distant n'a pas récepteur de canal qui désigne soit le serveur n'a pas canaux de serveur enregistrés qui sont à l'écoute, ou cette application n'a pas de canal client approprié pour communiquer avec le serveur. »
La cause est mieux expliqué par cette entrée de blog j'ai trouvé:
Le second cas est plus obscure. Cette
se produit lorsque le client fait un appel
sur le serveur, le serveur renvoie un
référence d'objet, et le client puis
fait un appel sur l'objet référencé
sur le serveur. Si la référence
objet est dans un domaine d'application secondaire
le serveur l'exception ci-dessus peut être
jeté. Si le problème se produit, il
est parce que l'enregistrement du canal uniquement
applique au domaine d'application dans lequel
RegisterChannel est appelé et pas
le canal a été enregistré dans le
AppDomain secondaire. L'object
référence retournée au client
les points de l'objet dans le secondaire
Appdomain, et non à son mandataire dans la
AppDomain primaire, et donc il n'y a pas
canal entre le client et le
AppDomain secondaire à travers lequel le
appel peut passer. Solution: un registre
canal dans le domaine d'application secondaire
qui l'objet référencé existe.
Cela ne correspond mon scénario que j'ai un service que les plugins de charge dans AppDomains séparés. les instances de l'objet (implémentations d'une interface définie dans un ensemble référencé par tous les ensembles) sont créés dans les domaines d'application secondaire et référencé par le service (cross-appdomain, de sorte que le service a des références proxy). Le service retourne ensuite ces références proxy à une application. Il existe des canaux enregistrés entre l'application et le service, mais rien entre le plug-in et l'application.
Je pensais qu'un proxy serait suffisant pour franchir les frontières AppDomain. Dois-je vraiment créer des canaux entre les plugins et l'application? Cela ne semble pas juste du tout, donc je dois manquer quelque chose.
3 Réponses :
Afin d'utiliser des distions à travers AppDomains sur des objets dérivés de MarshalbyRefObject, il est nécessaire de créer des canaux aux deux extrémités. Ainsi, vous devez créer des canaux dans chaque AppDomain. Il existe des canaux efficaces pour le faire localement sur la même machine. Le canal IPC (utilise des tuyaux nommés).
Si la communication est "à sens unique", dans le sens où un seul des côtés appelle des méthodes sur les proxies, vous enregistrez une chaîne client ici, et le canal du serveur sur le côté qui crée les objets. p>
au cas où vous auriez besoin d'aller dans les deux sens, par exemple Passez un objet de journalisation sur le "serveur" afin de recevoir un retour de journal continu, vous devez enregistrer un canal de serveur aux deux extrémités, car le client sert soudainement des objets: P>
class MyLogger : MarshalByRefObject
{
public Log(string text) { ... }
}
MyLogger logger = new MyLogger();
proxyObj.LongRunningCommand(logger);
Pour développer la réponse de @ Roncohen -
sur le serveur, on crée généralement une chaîne complète de manière amusante (surtout si vous souhaitez réparer le problème de TypeEvelfilter Problème ALA https://stackoverflow.com/a/9268223/344638 ): permet de dire que vous utilisez un sponsor sur le côté du client. Si vous ne le faites pas, et que le client n'appelle pas l'objet à distance pendant un moment, le serveur déposera l'objet: donc vous utilisez un sponsor, que le serveur appelle alors parfois pour renouveler l'objet reculé. Mais! Maintenant, le serveur a un objet recruté - le commanditaire est reculé au côté du serveur lorsque le sponsor appelle Donc, de la même manière que le serveur doit exposer un canal de télécommande au client pour accéder aux objets à distance. , le client doit exposer un canal de télécommandage sur le serveur du serveur pour pouvoir accéder à des objets à distance tels que sponsors. En fin de compte, mon côté client et mon côté serveur finissent par avoir le même code de construction de canaux (ci-dessus), sauf que j'utilise différents numéros de port de chaque côté. ileas.register . Mais si le serveur n'a pas de canal de télécommandage sur le client, cela échoue.
Pour les recherches sur le "Ce proxy de télécommandage n'a pas d'évier de canal ...", j'ai reçu cette erreur lorsque vous appelez une bibliothèque de VB.NET Com emballée de VBScript. Tout cela était sur la même machine Windows 7, il n'aurait donc pas dû n'avoir eu aucun problème de serveur client. Finalement, j'ai élaboré que l'erreur a été causée par moi-même en passant une charge de arraylistes rempli de chaînes plutôt que de remplir de simples simples, ce que la fonction que j'appelle était attendue. Je ne comprends pas pourquoi j'ai eu cette erreur, mais j'espère que cela pourrait aider quelqu'un à obtenir cette erreur.