Fonction .NET pour récupérer le nom de la procédure en cours

Bonjour,
Je souhaiterais créer une sub qui aurait en argument le nom de la procédure dans laquelle elle est appelée.
Mais comme je compte faire des appels dans plein de procédures. J'aimerais éviter d'avoir à "personnaliser" l'argument à chaque fois.

Au lieu d'écrire :

Code:

---

1 2 3 4 5 6 7 8 9

sub toto1() Maprocedure("toto1") end sub   sub toto2() Maprocedure("toto2") end sub   ...

---

je voudrais quelques chose comme

Code:

---

1 2 3 4 5 6 7 8 9

sub toto1() Maprocedure(methode) end sub   sub toto2() Maprocedure(methode) end sub   ...

---

où methode est une instruction .NET qui trouve automatiquement le nom de la procédure dans laquelle elle est utilisée.
Le but est de pouvoir faire des copier/coller rapidement...

Est-ce qu'une telle méthode existe ?

Sur le Net je n'ai rien trouvé.

Bonsoir,

Lorsqu'il s'agit d'inspecter dynamiquement une assembly on utilise "Reflection" :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Imports System.Reflection   '...... '........ sub toto1() Maprocedure(System.Reflection.MethodBase.GetCurrentMethod().Name) end sub   '...... '........

---

A+

Super,
Un grand merci.
J'avais pourtant cherché du coté de system.reflection mais je n'avais pas trouvé. C'est balot !

Pour ceux utilisant au moins VS2012 (et donc les dernières versions des compilateurs C#/VB.Net) il existe une alternative plus qu'intéressante ; à savoir CallerMemberName (il existe aussi CallerFilePath et CallerLinerNumber au besoin)

Ses avantages sont multiples, déjà une fois en place, ce n'est plus à celui utilisant la méthode (MaProcédure ici) de passer la bonne chose, cela se fait automatiquement, ensuite par exemple en cas d'utilisation de la méthode évoquée par wallace1 avec une propriété on obtiendra "get_NomProp" (ou "set_NomProp" selon si c'est sur l'accesseur ou le mutateur) chose qui n'est pas toujours ce que l'on souhaitait ; enfin, comme tout ce qui réside dans l'espace de noms System.Runtime.CompilerServices ; c'est à la compilation que se fait le boulot donc aucun surcoût à l'exécution contrairement à la Reflection dont parfois le coût est loin d'être négligeable.

Comment ça fonctionne ? c'est simple, à la compilation, le code est réécrit et l'argument utilisant CallerMemberName est remplacé par la bonne valeur directement dans le code (comme si on l'avait passé nous-mêmes) mais c'est fait automatiquement et de manière transparente donc même si on change le nom un jour, après recompilation le nouveau nom sera lui-aussi présent dans l'appel.

Comment on l'utilise ? on marque juste l'argument de notre procédure avec l'attribut CallerMemberName ; seules contraintes, cet argument doit être de type String (normal) ET être optionnel :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

' Imports System.Runtime.CompilerServices   Sub MaProcedure (<CallerMemberName> Optional memberName As String = "") ' utilisation de memberName qui contient le nom de l'appelant End Sub   ' exemples d'utilisation Sub Toto1 () MaProcedure () 'on ne passe rien c'est le compilo qui s'en chargera (d'où la nécessité du paramètre optionnel) ' après compilation le code sera comme ceci ' MaProcedure ("Toto1") End Sub   ReadOnly Property Foo As Integer Get MaProcedure () ' même principe avec une propriété ' après compilation : ' Maprocedure ("Foo") Return 42 End Get End Property

---

Rien n'empêche de mettre d'autres paramètres à MaProcedure (par exemple un message à passer en même temps), il faudra juste qu'il soit spécifié avant dans la liste des arguments (vu qu'une fois qu'il y a des paramètres optionnels, tous ceux qui suivent doivent l'être aussi) ; exemple :

Code:

---

1 2 3

Sub MaProcedure (message As String, <CallerMemberName> Optionnal memberName As String = "") Log.Write("In {0} : {1}", memberName, message) ' exemple End Sub

---

Par contre, une chose en garder en tête (enfin à vérifier surtout) ; c'est comment se comporte ceci dans le cadre d'une obfuscation du code ; comme le compilateur remplace l'appel en y précisant le nom de l'appelant ; et que certains obfuscateurs réécrivent le nom des méthodes, il se peut que ça donne des incohérences (ou que ce type d'appel continue d'apparaitre "en clair" chose potentielle problématique dans ce type de scénario). Après je n'ai personnellement jamais utilisé d'obfuscateurs ; si ça se trouve il gèrent très bien les choses mais dans le doute je préfère prévenir :D

Citation:

---

Envoyé par Sehnsucht

Par contre, une chose en garder en tête (enfin à vérifier surtout) ; c'est comment se comporte ceci dans le cadre d'une obfuscation du code ; comme le compilateur remplace l'appel en y précisant le nom de l'appelant ; et que certains obfuscateurs réécrivent le nom des méthodes, il se peut que ça donne des incohérences (ou que ce type d'appel continue d'apparaitre "en clair" chose potentielle problématique dans ce type de scénario). Après je n'ai personnellement jamais utilisé d'obfuscateurs ; si ça se trouve il gèrent très bien les choses mais dans le doute je préfère prévenir :D

---

En effet cet article : Caller Details confirme que c'est bien le nom de substitution qui sera utilisé.

Merci Sehn c'est effectivement très intéressant ce que tu nous proposes là. :ccool:

Merci pour cette autre méthode.
Je m'en souviendrai si je passe sur VS 2012. Actuellement je travaille avec VS 2010 Ultimate