Perché Reflector è un'utilità essenziale?

Ecco un esempio perfetto di il tipo di domanda che .NET Reflector può rispondere per te.

Oppure puoi postarlo su SO e lasciare che qualcun altro con Reflector installato risponda per te. ;)

Uso il riflettore su base abbastanza regolare (forse una o due volte alla settimana in media) per aiutare con due diversi problemi.

1. API / libreria scarsamente documentate: il mio esempio preferito è SharePoint. La maggior parte degli sviluppatori che conosco di sviluppo SharePoint lo utilizza per integrare la documentazione disponibile. Potremmo cavarcela senza, per la maggior parte sì; ma ci sono stati un certo numero di casi in cui sarebbe stato piuttosto difficile.

2. Debug di un errore oscuro: può anche essere utile per capire perché qualcosa sta generando un'eccezione. Se riesci a vedere dove si è verificata l'eccezione, puoi risalire alla catena di chiamate per capire qual è il problema (usando in modo errato una libreria, un bug, ecc.).

Reflector è essenziale quando hai alcuni assembly di terze parti che devi usare ed è scarsamente documentato o contiene bug e vuoi sapere cosa sta succedendo con il suo codice.

Certo, tutto ciò che devi fare è offuscare il tuo codice e Reflector è inutile (o era l'ultima volta che ho controllato) ma mi ha risparmiato un sacco di tempo e frustrazione in passato.

Inoltre, ho avuto almeno un'occasione in cui ho perso il codice sorgente (nella mia era di controllo pre-versione) ma il codice compilato e Reflector mi hanno aiutato a recuperare il mio codice. Ho bisogno di molto lavoro perché commenti, nomi di variabili, ecc. Sono sbagliati, ma mi ha aiutato.

Inoltre, a volte hai codice in, per esempio, VB.NET e vuoi vedere come sarebbe fatto, diciamo, in C # e Reflector può passare da una lingua all'altra.

Quando si utilizza Reflection.Emit per generare assiemi in fase di runtime, Reflector diventa uno strumento estremamente prezioso per la verifica visiva del codice generato come previsto.

Reflector ti aiuta a scoprire quando la documentazione è sbagliata. Ho trovato un bug nella documentazione StringBuilder del CLR molto indietro in .NET 1.1. La documentazione per la proprietà Lunghezza detto questo:

If the specified length is greater than the current length, the end of the string value of this instance is padded with spaces.

Ho provato a usare StringBuilder con questo in mente, ottenendo risultati bizzarri. Ho usato Reflector e ho visto il problema. La documentazione per la proprietà Lunghezza in .NET 2.0 e in avanti ha le informazioni corrette:

If the specified length is greater than the current length, the end of the string value of the current StringBuilder object is padded with the Unicode NULL character (U+0000).

Questo può fare una grande differenza se, per esempio, stai visualizzando il testo risultante con un MessageBox; MessageBox taglia il testo al primo carattere null.

Reflector consente di scoprire cose come questa, per vedere come si comporta veramente , in contrasto con ciò che dice la documentazione, o per rispondere a domande a cui la documentazione non risponde.

A volte è più semplice capire cosa sta facendo una libreria, come la sta facendo e usarla appropriatamente osservando il suo codice sorgente.

Altre volte, sono semplicemente curioso e voglio dare un'occhiata.

Un altro modo comune in cui utilizzo Reflector è vedere come il Framework stesso implementa qualcosa.

A volte, ho una libreria utilizzata in un progetto molto vecchio e non abbiamo alcun codice sorgente o documentazione. Reflector è abbastanza inestimabile in quelle situazioni.

L'ho usato anche per gli assembly hot patch. Ci sono stati alcuni casi in cui ho avuto bisogno di modificare un bit interno di una libreria che non posso ricostruire e usare Reflector per trovare il punto appropriato e quindi modificare l'IL del assembly (no, non sto parlando di cracking, ma degli usi legittimi di questa funzionalità).

Non direi che è essenziale. Ma nei rari casi in cui ne hai davvero bisogno, è molto utile.

Fai un esempio.

Recentemente ho dovuto creare una parte di codice che potesse eseguire il runtime per creare l'albero delle espressioni per quanto segue, ma senza conoscere il nome della proprietà dipendente al momento della compilazione:

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

Per impostare dinamicamente un mock (usando il framework Moq).

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

Quello che ho fatto è stato che ho compilato l'espressione originale utilizzando tipi concreti, quindi utilizzando reflector, ho scoperto che dovevo scrivere il seguente codice:

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;    

Sarei stato in grado di capirlo usando prove ed errori. Ma Reflector ha reso tutto più semplice.

Perché se sai come usarlo, non hai bisogno di documentazione e la maggior parte delle API non ha una documentazione significativa.