Perché Reflector è un'utilità così essenziale?

Leggendo il brouhaha che circonda Reflector, mi viene in mente il prodotto e i suoi usi. Molte persone sembrano considerarlo uno strumento essenziale.

Devo ammettere che non uso Reflector da anni. Voglio dire, c'è la documentazione sia per le API .Net che per i componenti di terze parti che utilizzo. In passato, ogni volta che un collega estraeva il Riflettore dalla cintura degli attrezzi, ho avuto la sensazione che fosse diretto verso le erbacce.

Leggere tutta la passione di Reflector mi porta a chiedermi se mi manca davvero qualcosa qui. Perché hai bisogno di qualcosa come Reflector così spesso da considerarlo uno strumento essenziale? Vedo che è necessario in occasioni molto rare, ma non abbastanza per essere considerato uno strumento essenziale. Per favore, illuminami.

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

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

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

1. API / libreria scarsamente documentata: il mio esempio preferito per questo è SharePoint. Quasi tutti gli sviluppatori che conosco per lo sviluppo di SharePoint lo usano per integrare la documentazione disponibile. Potremmo cavarcela senza di essa, per la maggior parte sì; ma ci sono stati diversi casi in cui sarebbe stato piuttosto difficile.

2. Debug di un oscuro errore: 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 (utilizzando erroneamente una libreria, un bug, ecc.).

Reflector è essenziale quando si dispone di un assembly di terze parti che è necessario utilizzare ed è scarsamente documentato o contiene bug e si desidera 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 avevo il codice compilato e Reflector mi ha aiutato a recuperare il mio codice. Ha richiesto molto lavoro perché commenti, nomi di variabili, ecc. Sono sbagliati ma ha aiutato.

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

Quando si utilizza Reflection.Emit per generare assiemi in fase di esecuzione, Reflector diventa uno strumento estremamente utile per verificare visivamente che il codice generato sia come previsto.

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

Se la lunghezza specificata è maggiore della lunghezza corrente, la fine del valore di stringa di questa istanza viene riempita di spazi.

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

Se la lunghezza specificata è maggiore della lunghezza corrente, la fine del valore di stringa dell'oggetto StringBuilder corrente viene riempita con il carattere NULL Unicode (U + 0000).

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

Reflector consente di scoprire cose come queste, di vedere come si comporta realmente il CLR , al contrario di quanto afferma la documentazione, o di rispondere a domande alle quali la documentazione non risponde.

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

Altre volte, sono semplicemente curioso e voglio sbirciare.

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. Il riflettore è abbastanza prezioso in quelle situazioni.

L'ho usato anche per gli assembly hot-patch. Ci sono stati alcuni casi in cui ho dovuto modificare una parte interna di una libreria che non posso ricostruire e usare Reflector per trovare il punto appropriato e quindi modificare l'IL dell'assembly (no, non sto parlando di cracking, ma 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 un pezzo di codice che potrebbe runtime creare l'albero delle espressioni per quanto segue, ma senza conoscere il nome della proprietà dipendente in fase di compilazione:

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

Al fine di impostare dinamicamente una simulazione (usando il framework Moq).

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

Quello che ho fatto è stato che ho compilato l'espressione originale usando tipi concreti, quindi usando 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 tentativi ed errori. Ma il riflettore lo ha reso facile.

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