Comment invoquer une méthode dont on connait le nom à l’exécution sur un dynamic?
Publié par Fabrice Michellonet sous le(s) label(s) C# , dynamic le 24 juillet 2015
Comment invoquer une méthode dont on connait le nom à l'exécution sur un dynamic?
Le mot clé dynamic en C# n'est pas nouveau, il a vu le jour avec C# 4 et pourtant il n’apparaît pas si souvent que ça dans les bouts de code que je fréquente.
Dernièrement je l'ai recroisé en utilisant SignalR; les hubs qui sont générés sont des objets dynamic.
Quoi qu'il en soit, dernièrement j'ai eu besoin d'invoquer une méthode dont le nom ne m'était connu qu'à l'exécution.
Croyez-moi, j'y ai passé un petit moment avant d'y arriver... Cela révèle vraisemblablement ma grande ignorance :)
Ce blog post prendra donc la forme d'un post-it qui me fera gagner du temps la prochaine fois que je me frotterai a cette bête-là. Si pour vous les classes Binder et CallSite n'ont plus de secret ce blog post vous semblera vraisemblablement bien terne.
Posons le problème, on me donne un objet dynamic auquel une méthode est ajoutée à l'exécution
Si j'avais connaissance de la méthode lors de la compilation je pourrais l'appeler ainsi :
Malheureusement la signature de la méthode ne m'est connue qu'à l'exécution.
Ok, premier réflexe je sors l'attirail de la reflection.... mais les résultats restent catastrophiques :
Quels que soient les bindings flags, impossible de trouver la méthode... FAIL!!
Voici, donc la combinaison magique, un savant mélange de Runtime.Binder et CallSite...
Ok, essayons de décrypter un peu ce code qui semble un peu alambiqué.
Binder.InvokeMember va nous permettre à l'exécution de pointer la bonne méthode un peu comme le ferait typeof(myObj).GetMethod()
Le premier paramètre permet de spécifier la manière dont est traité le type de retour. Dans le cas d'une Action nous aurions pu utiliser CSharpBinderFlags.ResultDiscarded. Dans notre cas, une Func, CSharpBinderFlags.None fonctionne bien.
puis viens en seconde position, évidement le nom de la méthode a appelé, passée sous forme de chaine.
En troisième position, il conviendra de fournir la liste des arguments de types à nécessaire dans le cas d'une méthode générique.
Viens ensuite le type sur lequel effectuer l'invocation, ce qui permet de pointer une surcharge.
Et finalement les informations sur les paramètres attendus et le type de retour (le premier élément du tableau);
La création du CallSite<Func<CallSite, object, object>> permet d'arrêter la signature du delegate que l'on cherche à appeler. Notez, que le dernier argument générique "object" devrait etre "string", car il représente le type de retour de la func... mais pour une raison qui m'échappe l'utilisation de string comme type de retour entraîne une erreur au runtime, alors que le retour de la func est bien affecté à une variable string à la ligne du dessous... il faut bien garder un peu de magie :)
Ok, évidemment il ne nous reste plus qu'à effectuer l'invocation, ce qui est réalisé via le code callSite.Target(callSite, myObj);
J'espère que ce post évitera quelques cheveux blancs a ceux qui se trouveront confronté au problème.
Le mot clé dynamic en C# n'est pas nouveau, il a vu le jour avec C# 4 et pourtant il n’apparaît pas si souvent que ça dans les bouts de code que je fréquente.
Dernièrement je l'ai recroisé en utilisant SignalR; les hubs qui sont générés sont des objets dynamic.
Quoi qu'il en soit, dernièrement j'ai eu besoin d'invoquer une méthode dont le nom ne m'était connu qu'à l'exécution.
Croyez-moi, j'y ai passé un petit moment avant d'y arriver... Cela révèle vraisemblablement ma grande ignorance :)
Ce blog post prendra donc la forme d'un post-it qui me fera gagner du temps la prochaine fois que je me frotterai a cette bête-là. Si pour vous les classes Binder et CallSite n'ont plus de secret ce blog post vous semblera vraisemblablement bien terne.
Posons le problème, on me donne un objet dynamic auquel une méthode est ajoutée à l'exécution
private string sentence = "Hello world"; public dynamic BuildObj() { dynamic myDynObj = new ExpandoObject(); myDynObj.SayHello = new Func<string>(() => sentence); return myDynObj; }
Si j'avais connaissance de la méthode lors de la compilation je pourrais l'appeler ainsi :
[Test] public void CallDirectlyMethod() { dynamic myObj = BuildObj(); var ret = myObj.SayHello(); Assert.That(ret, Is.EqualTo(sentence)); }
Malheureusement la signature de la méthode ne m'est connue qu'à l'exécution.
Ok, premier réflexe je sors l'attirail de la reflection.... mais les résultats restent catastrophiques :
[Test] public void CallMethodWithReflectionFails() { dynamic myObj = BuildObj(); Type t = myObj.GetType(); var method = t.GetMethod("SayHello", BindingFlags.Default | BindingFlags.Instance | BindingFlags.InvokeMethod | BindingFlags.NonPublic); Assert.That(method, Is.Null); }
Quels que soient les bindings flags, impossible de trouver la méthode... FAIL!!
Voici, donc la combinaison magique, un savant mélange de Runtime.Binder et CallSite...
[Test] public void CallMethodWithCallSite() { dynamic myObj = BuildObj(); var callSiteBinder = Binder.InvokeMember(CSharpBinderFlags.None, "SayHello", Enumerable.Empty<Type>(), myObj.GetType(), new [] { CSharpArgumentInfo.Create(CSharpArgumentInfoFlags.None, null) }); var callSite = CallSite<Func<CallSite, object, object>>.Create(callSiteBinder); string ret = callSite.Target(callSite, myObj); Assert.That(ret, Is.EqualTo(sentence)); }
Ok, essayons de décrypter un peu ce code qui semble un peu alambiqué.
Binder.InvokeMember va nous permettre à l'exécution de pointer la bonne méthode un peu comme le ferait typeof(myObj).GetMethod()
Le premier paramètre permet de spécifier la manière dont est traité le type de retour. Dans le cas d'une Action nous aurions pu utiliser CSharpBinderFlags.ResultDiscarded. Dans notre cas, une Func, CSharpBinderFlags.None fonctionne bien.
puis viens en seconde position, évidement le nom de la méthode a appelé, passée sous forme de chaine.
En troisième position, il conviendra de fournir la liste des arguments de types à nécessaire dans le cas d'une méthode générique.
Viens ensuite le type sur lequel effectuer l'invocation, ce qui permet de pointer une surcharge.
Et finalement les informations sur les paramètres attendus et le type de retour (le premier élément du tableau);
La création du CallSite<Func<CallSite, object, object>> permet d'arrêter la signature du delegate que l'on cherche à appeler. Notez, que le dernier argument générique "object" devrait etre "string", car il représente le type de retour de la func... mais pour une raison qui m'échappe l'utilisation de string comme type de retour entraîne une erreur au runtime, alors que le retour de la func est bien affecté à une variable string à la ligne du dessous... il faut bien garder un peu de magie :)
Ok, évidemment il ne nous reste plus qu'à effectuer l'invocation, ce qui est réalisé via le code callSite.Target(callSite, myObj);
J'espère que ce post évitera quelques cheveux blancs a ceux qui se trouveront confronté au problème.