Warum ist Reflektor so wichtig?

Als ich das Brouhaha um Reflector las, das bezahlt wurde, dachte ich über das Produkt und seine Verwendung nach. Viele Leute scheinen es als ein wesentliches Werkzeug zu betrachten.

Ich muss zugeben, ich habe Reflector seit Jahren nicht mehr benutzt. Ich meine, es gibt Dokumentation sowohl für die .NET-APIs als auch für die von mir verwendeten Komponenten von Drittanbietern. In der Vergangenheit hatte ich immer dann, wenn ein Kollege Reflector aus seinem Werkzeuggürtel zog, das Gefühl, dass er ins Unkraut getrieben wurde.

Das Lesen der ganzen Leidenschaft rund um Reflector führt mich zu der Frage, ob mir hier wirklich etwas fehlt. Warum brauchen Sie so etwas wie Reflektor so oft, dass Sie es für ein wesentliches Werkzeug halten? Ich kann sehen, dass es in sehr seltenen Fällen benötigt wird, aber nicht genug, um als wesentliches Werkzeug angesehen zu werden. Bitte erleuchte mich.

Hier ist ein perfektes Beispiel für die Art der Frage, die .NET Reflector für Sie beantworten kann.

Oder Sie können es auf SO posten und es von jemand anderem mit installiertem Reflector beantworten lassen. ;)

Ich benutze den Reflektor ziemlich regelmäßig (vielleicht ein- oder zweimal pro Woche im Durchschnitt), um bei zwei verschiedenen Problemen zu helfen.

1. Schlecht dokumentierte API / Bibliothek: Mein Lieblingsbeispiel hierfür ist SharePoint. Fast jeder Entwickler, den ich für die SharePoint-Entwicklung kenne, verwendet es, um die verfügbare Dokumentation zu ergänzen. Könnten wir ohne auskommen, größtenteils ja; Aber es gab eine Reihe von Fällen, in denen es ziemlich schwierig gewesen wäre.

2. Debuggen eines obskuren Fehlers: Dies kann auch hilfreich sein, um herauszufinden, warum etwas eine Ausnahme auslöst. Wenn Sie sehen können, wo die Ausnahme aufgetreten ist, können Sie die Aufrufkette zurückverfolgen, um herauszufinden, um welches Problem es sich handelt (entweder bei falscher Verwendung einer Bibliothek, eines Fehlers usw.).

Reflektor ist wichtig, wenn Sie eine Assembly eines Drittanbieters verwenden müssen, die entweder schlecht dokumentiert ist oder Fehler enthält, und Sie möchten wissen, was mit dem Code los ist.

Sicher, alles was Sie tun müssen, ist Ihren Code zu verschleiern und Reflector ist nutzlos (oder es war das letzte Mal, dass ich es überprüft habe), aber es hat mir in der Vergangenheit viel Zeit und Frust erspart.

Außerdem hatte ich mindestens eine Gelegenheit, bei der ich den Quellcode verloren habe (in meiner Zeit vor der Versionskontrolle), aber der kompilierte Code und Reflector haben mir geholfen, meinen Code zurückzubekommen. Ich brauchte viel Arbeit, weil Kommentare, Variablennamen usw. falsch sind, aber es hat geholfen.

Manchmal haben Sie auch Code in beispielsweise VB.NET und möchten sehen, wie dies beispielsweise in C # geschehen würde, und Reflector kann zwischen den verschiedenen Sprachen wechseln.

Wenn Sie Reflection.Emit verwenden, um Assemblys zur Laufzeit zu generieren, wird Reflector zu einem äußerst wertvollen Werkzeug für die visuelle Überprüfung des generierten Codes, wie Sie es erwarten.

Mit Reflector können Sie feststellen, wenn die Dokumentation falsch ist. Ich habe vor langer Zeit in .NET 1.1 einen Fehler in der StringBuilder-Dokumentation der CLR gefunden. In der Dokumentation für die Length- Eigenschaft heißt es:

Wenn die angegebene Länge größer als die aktuelle Länge ist, wird das Ende des Zeichenfolgenwerts dieser Instanz mit Leerzeichen aufgefüllt.

Ich habe versucht, den StringBuilder in diesem Sinne zu verwenden, und dabei bizarre Ergebnisse erzielt. Ich habe Reflector verwendet und das Problem gesehen. Die Dokumentation für die Length- Eigenschaft in .NET 2.0 und höher enthält die richtigen Informationen:

Wenn die angegebene Länge größer als die aktuelle Länge ist, wird das Ende des Zeichenfolgenwerts des aktuellen StringBuilder-Objekts mit dem Unicode-Zeichen NULL (U + 0000) aufgefüllt.

Dies kann einen großen Unterschied machen, wenn Sie beispielsweise den resultierenden Text mit einer MessageBox anzeigen. Die MessageBox schneidet den Text beim ersten Nullzeichen ab.

Reflector ermöglicht es, solche Dinge herauszufinden, zu sehen, wie sich die CLR wirklich verhält, im Gegensatz zu dem, was in der Dokumentation steht, oder Fragen zu beantworten, die die Dokumentation einfach nicht beantwortet.

Manchmal ist es einfacher zu verstehen, was eine Bibliothek tut, wie sie es tut, und sie angemessen zu verwenden, indem man sich ihren Quellcode ansieht.

Ein anderes Mal bin ich einfach neugierig und möchte einen Blick darauf werfen.

Eine andere übliche Art, wie ich Reflector verwende, ist zu sehen, wie das Framework selbst etwas implementiert.

Gelegentlich habe ich eine Bibliothek, die in einem wirklich alten Projekt verwendet wird, und wir haben keinen Quellcode oder keine Dokumentation. Reflektor ist in solchen Situationen von unschätzbarem Wert.

Ich habe es auch zum Hot-Patch von Assemblys verwendet. Es gab einige Fälle, in denen ich ein internes Teil einer Bibliothek optimieren musste, das ich nicht neu erstellen und Reflector verwenden konnte, um den geeigneten Punkt zu finden und dann die IL der Assembly zu ändern (nein, ich spreche nicht von Cracking, sondern von legitimen Verwendungen von diese Funktionalität).

Ich würde nicht sagen, dass es wesentlich ist. Aber in den seltenen Fällen, in denen Sie es wirklich brauchen, ist es sehr nützlich.

Nehmen Sie ein Beispiel.

Vor kurzem musste ich einen Code erstellen, der zur Laufzeit den Ausdrucksbaum für Folgendes erstellen konnte, ohne jedoch den Namen der abhängigen Eigenschaft zur Kompilierungszeit zu kennen:

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

Um ein Modell dynamisch einzurichten (unter Verwendung des Moq-Frameworks).

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

Was ich tat, war, dass ich den ursprünglichen Ausdruck mit konkreten Typen kompilierte und dann mit Reflektor herausfand, dass ich den folgenden Code schreiben musste:

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;    

Ich hätte dies mit Versuch und Irrtum herausfinden können. Aber der Reflektor machte es einfach.

Denn wenn Sie wissen, wie man es benutzt, brauchen Sie keine Dokumentation - und die meisten APIs haben keine aussagekräftige Dokumentation.