Pourquoi Reflector est-il un utilitaire si essentiel?

La lecture du brouhaha entourant le réflecteur payé m'a fait penser au produit et à ses utilisations. Beaucoup de gens semblent le considérer comme un outil essentiel.

Je dois admettre que je n'ai pas utilisé Reflector depuis des années. Je veux dire, il y a de la documentation pour les API .Net et les composants tiers que j'utilise. Dans le passé, chaque fois qu'un collègue sortait Reflector de sa ceinture à outils, j'ai l'impression qu'il se dirigeait vers les mauvaises herbes.

Lire toute la passion autour de Reflector me conduit à me demander si je manque vraiment quelque chose ici. Pourquoi avez-vous besoin de quelque chose comme Reflector si souvent que vous le considérez comme un outil essentiel? Je peux voir qu'il est nécessaire en de très rares occasions, mais pas assez pour être considéré comme un outil essentiel. Veuillez m'éclairer.

Voici un exemple parfait du type de question .NET Reflector peut répondre pour vous.

Ou vous pouvez le publier sur SO et laisser quelqu'un d'autre avec Reflector installé y répondre pour vous. ;)

J'utilise le réflecteur sur une base assez régulière (peut-être une ou deux fois par semaine en moyenne) pour aider avec deux problèmes différents.

1. API / bibliothèque mal documentée: mon exemple préféré est SharePoint. La plupart des développeurs que je connais dans le développement SharePoint l'utilisent pour compléter la documentation disponible. Pouvons-nous nous en passer, pour la plupart oui; mais il y a eu un certain nombre de cas où cela aurait été assez difficile.

2. Débogage d'une erreur obscure: elle peut également être utile pour comprendre pourquoi quelque chose lève une exception. Si vous pouvez voir où l'exception s'est produite, vous pouvez retracer la chaîne d'appels pour déterminer quel est le problème (soit en utilisant incorrectement une bibliothèque, un bogue, etc.).

Reflector est essentiel lorsque vous avez un assemblage tiers que vous devez utiliser et qu'il est mal documenté ou contient des bogues et que vous voulez savoir ce qui se passe avec son code.

Bien sûr, tout ce que vous avez à faire est d'obscurcir votre code et Reflector est inutile (ou c'était la dernière fois que j'ai vérifié), mais cela m'a fait gagner beaucoup de temps et de frustration dans le passé.

De plus, j'ai eu au moins une occasion où j'ai perdu du code source (à mon époque de contrôle de pré-version) mais j'ai eu le code compilé et Reflector m'a aidé à récupérer mon code. Besoin de beaucoup de travail car les commentaires, les noms de variables, etc. sont faux mais cela a aidé.

De plus, parfois, vous avez du code dans, disons, VB.NET et vous voulez voir comment cela serait fait dans, disons, C # et Reflector peut basculer entre les différents langages.

Lorsque vous utilisez Reflection.Emit pour générer des assemblys au moment de l'exécution, Reflector devient un outil extrêmement précieux pour vérifier visuellement le code généré comme vous vous y attendez.

Reflector vous aide à découvrir quand la documentation est fausse. J'ai trouvé un bogue dans le chemin de la documentation StringBuilder du CLR dans .NET 1.1. La documentation de la propriété Length indique ceci:

Si la longueur spécifiée est supérieure à la longueur actuelle, la fin de la valeur de chaîne de cette instance est complétée par des espaces.

J'ai essayé d'utiliser le StringBuilder dans cet esprit, et j'ai obtenu des résultats bizarres. J'ai utilisé Reflector et j'ai vu le problème. La documentation de la propriété Length dans .NET 2.0 et versions ultérieures contient les informations correctes:

Si la longueur spécifiée est supérieure à la longueur actuelle, la fin de la valeur de chaîne de l'objet StringBuilder actuel est complétée par le caractère Unicode NULL (U + 0000).

Cela peut faire une grande différence si, par exemple, vous affichez le texte résultant avec un MessageBox; le MessageBox coupe le texte au premier caractère nul.

Reflector permet de découvrir des choses comme celle-ci, de voir comment le CLR se comporte vraiment , par opposition à ce que dit la documentation, ou de répondre à des questions auxquelles la documentation ne répond tout simplement pas.

Parfois, il est plus simple de comprendre ce qu'une bibliothèque fait, comment elle le fait et de l'utiliser de manière appropriée en consultant son code source.

D'autres fois, je suis simplement curieux et je veux jeter un œil.

Une autre façon courante d'utiliser Reflector est de voir comment le Framework lui-même implémente quelque chose.

À l'occasion, j'ai une bibliothèque utilisée dans un projet très ancien et nous n'avons ni code source ni documentation. Le réflecteur est très précieux dans ces situations.

Je l'ai également utilisé pour assembler des correctifs à chaud. Il y a eu quelques cas où j'ai dû modifier une partie interne d'une bibliothèque que je ne peux pas reconstruire et utiliser Reflector pour trouver le point approprié, puis modifier l'IL de l'assembly (non, je ne parle pas de craquage, mais des utilisations légitimes de cette fonctionnalité).

Je ne dirais pas que c'est essentiel. Mais dans les rares cas où vous en avez vraiment besoin, c'est très utile.

Prenons un exemple.

Récemment, j'ai dû créer un morceau de code qui pourrait au moment de l'exécution créer l'arborescence d'expression pour les éléments suivants, mais sans connaître le nom de la propriété dépendante au moment de la compilation:

Expression<Func<TMock, TDependency>> expression = (x => x.Dependency);

Afin de configurer dynamiquement une maquette (en utilisant le framework Moq).

mock.Setup(expression).Returns(dependency);

Ce que j'ai fait, c'est que j'ai compilé l'expression originale en utilisant des types concrets, puis en utilisant un réflecteur, j'ai découvert que je devais écrire le code suivant:

var argument = Expression.Parameter(typeof(TMock), "x");
var getPropertyExpression = Expression.Property(argument, propertyInfo.Name);
var lambda = Expression.Lambda<Func<TMock, TDependency>>(getPropertyExpression, argument);            
Expression<Func<TMock, TDependency>> expression = lambda;    

J'aurais pu comprendre cela à l'aide d'essais et d'erreurs. Mais le réflecteur l'a rendu facile.

Parce que si vous savez comment l'utiliser, vous n'avez pas besoin de documentation - et la plupart des API n'ont pas de documentation significative.