Por que o Reflector é um utilitário tão essencial?

A leitura do brouhaha em torno do Reflector sendo pago me fez pensar sobre o produto e seus usos. Muitas pessoas parecem considerá-lo uma ferramenta essencial.

Eu tenho que admitir, eu não uso o Reflector há anos. Quero dizer, há documentação para as APIs .Net e os componentes de terceiros que eu uso. No passado, sempre que um colega puxava Reflector para fora do cinto de ferramentas, eu sentia que ele estava indo para o mato.

Ler toda a paixão em torno do Reflector está me levando a questionar se realmente estou perdendo alguma coisa aqui. Por que você precisa de algo como o Refletor com tanta frequência que o considera uma ferramenta essencial? Percebo que isso é necessário em ocasiões muito raras, mas não o suficiente para ser considerado uma ferramenta essencial. Por favor me esclareça.

Aqui está um exemplo perfeito do tipo de pergunta que o .NET Reflector pode responder por você.

Ou você pode publicá-lo no SO e deixar que outra pessoa com o Reflector instalado responda por você. ;)

Eu uso o refletor regularmente (talvez uma ou duas vezes por semana, em média) para ajudar com dois problemas diferentes.

1. API / biblioteca mal documentada: meu exemplo favorito disso é o SharePoint. Quase todos os desenvolvedores que eu conheço desenvolvendo o SharePoint o utilizam para complementar a documentação disponível. Poderíamos sobreviver sem ele, na maior parte sim; mas houve vários casos em que teria sido bastante difícil.

2. Depurando um erro obscuro: também pode ser útil para descobrir por que algo está lançando uma exceção. Se você puder ver onde ocorreu a exceção, poderá rastrear novamente a cadeia de chamadas para descobrir qual é o problema (usando incorretamente uma biblioteca, bug etc.).

O refletor é essencial quando você tem alguma montagem de terceiros que precisa usar e ela está mal documentada ou possui bugs e você deseja saber o que está acontecendo com seu código.

Claro, tudo o que você precisa fazer é ofuscar seu código e o Reflector é inútil (ou foi a última vez que verifiquei), mas isso me salvou muito tempo e frustração no passado.

Além disso, tive pelo menos uma ocasião em que perdi o código fonte (na minha era de controle de pré-versão), mas o código compilado e o Reflector me ajudaram a recuperar meu código. Precisava de muito trabalho porque comentários, nomes de variáveis ​​etc. estão errados, mas isso ajudou.

Além disso, às vezes você tem código no VB.NET, por exemplo, e deseja ver como isso seria feito, digamos, em C # e o Reflector pode alternar entre os vários idiomas.

Ao usar o Reflection.Emit para gerar assemblies em tempo de execução, o Reflector se torna uma ferramenta extremamente valiosa para verificar visualmente o código gerado, conforme o esperado.

O Reflector ajuda a descobrir quando a documentação está errada. Eu encontrei um bug na documentação do CLB StringBuilder no .NET 1.1. A documentação para a propriedade Length dizia o seguinte:

Se o comprimento especificado for maior que o comprimento atual, o final do valor da sequência desta instância será preenchido com espaços.

Tentei usar o StringBuilder com isso em mente e obtive resultados bizarros. Eu usei o Reflector e vi o problema. A documentação para a propriedade Length no .NET 2.0 e forward tem as informações corretas:

Se o comprimento especificado for maior que o comprimento atual, o final do valor da string do objeto StringBuilder atual será preenchido com o caractere NULL Unicode (U + 0000).

Isso pode fazer uma grande diferença se, por exemplo, você estiver exibindo o texto resultante com uma MessageBox; o MessageBox corta o texto no primeiro caractere nulo.

O Reflector torna possível descobrir coisas como essa, ver como o CLR realmente se comporta, em oposição ao que a documentação diz, ou responder a perguntas que a documentação simplesmente não responde.

Às vezes, é mais simples entender o que uma biblioteca está fazendo, como está fazendo e usá-la adequadamente, observando seu código-fonte.

Outras vezes, sou simplesmente curioso e quero espiar.

Outra maneira comum de usar o Reflector é ver como o próprio Framework implementa algo.

Ocasionalmente, tenho uma biblioteca sendo usada em um projeto muito antigo e não temos nenhum código-fonte ou documentação. Refletor é bastante inestimável nessas situações.

Eu também o usei para hot-patch assemblies. Houve alguns casos em que precisei ajustar um pouco interno de uma biblioteca que não consigo reconstruir e usar o Reflector para encontrar o ponto apropriado e modificar a IL do assembly (não, não estou falando de cracking, mas de usos legítimos de essa funcionalidade).

Eu não diria que é essencial. Mas nos raros casos em que você realmente precisa, é altamente útil.

Veja um exemplo.

Recentemente, tive que criar um pedaço de código que pudesse criar a árvore de expressão em tempo de execução para o seguinte, mas sem saber o nome da propriedade dependente no momento da compilação:

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

Para configurar dinamicamente um mock (usando a estrutura Moq).

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

O que fiz foi compilar a expressão original usando tipos concretos e, em seguida, usando o refletor, descobri que precisava escrever o seguinte código:

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;    

Eu seria capaz de descobrir isso usando tentativa e erro. Mas o refletor facilitou.

Porque se você sabe como usá-lo, não precisa de documentação - e a maioria das APIs não possui documentação significativa.