Je regarde certains des articles de l'API de profilage CLR et beaucoup de ces articles parlent d'appel de la collaboration () pour faire la réécriture de l'IL; Cependant, aucun de ces articles n'explique en fait exactement ce que vous pourriez utiliser pour réécrire la méthode actuelle des octets. Y a-t-il une bibliothèque non gérée qui me permet d'écrire il ou que je devrais écrire un moi-même?
5 Réponses :
Je suppose que vous voulez faire cela parce que vous voulez voir ce qui prend du temps afin de pouvoir le faire aller plus vite (par opposition à une nouvelle information de synchronisation). IMHO, vous n'avez pas besoin de l'API du profilage, si vous pouvez exécuter votre application sous une IDE et la mettre en pause au hasard. Voici pourquoi.
Les octets réels doivent venir de quelque part et si vous utilisez simplement l'API de profilage, vous devez vous fournir vous-même. Cet article passe en profondeur sur la façon de le faire (probablement un de ceux que vous avez lu): http://msdn.microsoft.com/en-us/magazine/cc188743.aspx
Une technique plus «commune» est de réellement écrire quel que soit le code dont vous avez besoin dans la langue que vous préférez, puis la compilez à IL. Vous pouvez ensuite extraire les opcodes à la conception et les stocker dans lesquels vous pouvez les atteindre ou les extraire de votre IL compilé au moment de l'exécution et de la supporter où vous en avez besoin.
AFAIK Il n'y a pas de bibliothèques non gérées pour vous aider avec cela.
Cet article peut avoir ce que vous recherchez http://www.codeproject.com/kb/cs/il_rewriting.aspx
Ce n'est pas un mauvais article en fait - il a ses limites lorsqu'il s'agit de l'injection il, mais toujours l'un des rares qui couvrent le sujet
Probablement. Cela dépend.
Le projet mono a une bibliothèque appelée Cecil, que vous pouvez accéder ici:
Cependant, c'est le code géré, que vous ne pouvez pas appeler tout en profilant. Vous pouvez avoir quelques options comment:
# 1 introduit un tas de complexité supplémentaire. Votre profileur finirait par avoir plus de pièces mobiles que nécessaire. En outre, l'IPC introduit un tas de frais généraux supplémentaires.
# 2 prendrait beaucoup de temps. Étant donné que Cecil n'est toujours que la version 0.6, cela ne vaut peut-être pas le moment de le faire, vs écrit votre propre implémentation.
# 3 vous donnerait le plus grand degré de contrôle et seriez probablement le plus performant. Cependant, cela prendrait beaucoup plus d'efforts que n ° 1.
J'utilise déjà Cecil et je cherche une alternative non gérée.
Quand j'ai dit "probablement" je répondais à la question "Dois-je écrire le ma propre ....".
J'ai écrit un simple pour OpenCover https://github.com/sawilde/opencover que vous ou quelqu'un d'autre pour cette affaire peut trouver utile