2010-05-05 3 views
4

En essayant de trouver la cause possible d'une exception, je suis un chemin de code utilisant Reflector. J'ai plus profond et plus profond, mais a fini par à un appel de méthode qui ressemble à:Est-il possible de lier une méthode marquée avec MethodImplOptions.InternalCall à son implémentation?

[MethodImpl(MethodImplOptions.InternalCall)] 
private extern void SomeMethod(int someParameter); 

Ce balisage sur la méthode indique le cadre d'appeler une fonction C++ quelque part. Existe-t-il un moyen de savoir quelle méthode est réellement appelée, et à son tour quoi d'autre est susceptible d'être appelé? NB: Je ne veux pas vraiment voir le code source de cette méthode, je veux juste savoir les choses possibles qui pourraient jeter l'exception que je vois qui provient de cet appel de méthode.

Répondre

3

Les appels internes finissent par effectuer un appel à une fonction C++ dans le CLR. Vous pouvez les retrouver dans le Rotor source code. Regardez clr \ src \ vm \ ecall.cpp pour trouver le mappage du nom visible .NET au nom de la fonction CLR. Méfiez-vous que la source est datée.

+0

une combinaison de http://www.koders.com/cpp/fid006DC4C11F458707221DA6ED2ED9CC3C7AE12E11.aspx et http://www.koders.com/cpp/fidFB82C2FF644D476EBEFA132529BA1A6DCA264698.aspx J'ai réussi à obtenir ce que je voulais. – adrianbanks

0

Si vous voulez traquer les méthodes peuvent jeter un type d'exception, vous pouvez utiliser à travers http://www.red-gate.com/products/Exception_Hunter/index.htm

+0

J'étais au courant de cet outil. Est-ce qu'il détecte également les exceptions qui sont lancées à la suite du code dans les fonctions C++ du framework (par exemple, le lancement sur cette ligne -> http://www.koders.com/cpp/fidFB82C2FF644D476EBEFA132529BA1A6DCA264698.aspx#L1632)? – adrianbanks

Questions connexes