¿Por qué es Reflector una utilidad tan esencial?

La lectura de la maraña que rodea a Reflector y que me paga me hizo pensar en el producto y sus usos. Muchas personas parecen considerarlo una herramienta esencial.

Tengo que admitir que no he usado Reflector en años. Quiero decir, hay documentación tanto para las API de .Net como para los componentes de terceros que uso. En el pasado, cada vez que un colega sacaba a Reflector de su cinturón de herramientas, tenía la sensación de que se dirigía hacia la maleza.

Leer toda la pasión en torno a Reflector me lleva a preguntarme si realmente me falta algo aquí. ¿Por qué necesita algo como Reflector con tanta frecuencia que lo considera una herramienta esencial? Puedo ver que se necesita en muy raras ocasiones, pero no lo suficiente como para ser considerado una herramienta esencial. Por favor iluminame.

Aquí hay un ejemplo perfecto del tipo de pregunta que .NET Reflector puede responder por usted.

O puede publicarlo en SO y dejar que otra persona con Reflector instalado lo responda por usted. ;)

Utilizo el reflector de forma bastante regular (tal vez una o dos veces por semana en promedio) para ayudar con dos problemas diferentes.

1. API / Biblioteca mal documentada: mi ejemplo favorito para esto es SharePoint. La mayoría de los desarrolladores que conozco sobre el desarrollo de SharePoint lo usan para complementar la documentación disponible. ¿Podríamos pasar sin él, en su mayor parte sí; pero ha habido varios casos en los que hubiera sido bastante difícil.

2. Depuración de un error oscuro: también puede ser útil para descubrir por qué algo arroja una excepción. Si puede ver dónde se produjo la excepción, puede rastrear la cadena de llamadas para averiguar cuál es el problema (ya sea utilizando incorrectamente una biblioteca, error, etc.).

Reflector es esencial cuando tienes un ensamblado de terceros que tienes que usar y está mal documentado o tiene errores y quieres saber qué está pasando con su código.

Claro, todo lo que tienes que hacer es ofuscar tu código y Reflector es inútil (o fue la última vez que lo revisé), pero me ahorró mucho tiempo y frustración en el pasado.

Además, tuve al menos una ocasión en la que perdí el código fuente (en mi era de control previo a la versión) pero tuve el código compilado y Reflector me ayudó a recuperar mi código. Necesitaba mucho trabajo porque los comentarios, nombres de variables, etc. están mal pero ayudó.

Además, a veces tiene código en, por ejemplo, VB.NET y desea ver cómo se haría, por ejemplo, C # y Reflector pueden cambiar entre los distintos idiomas.

Cuando se utiliza Reflection.Emit para generar ensamblajes en tiempo de ejecución, Reflector se convierte en una herramienta extremadamente valiosa para verificar visualmente que el código generado es el esperado.

Reflector lo ayuda a descubrir cuándo la documentación es incorrecta. Encontré un error en la documentación de StringBuilder de CLR en .NET 1.1. La documentación de la propiedad Longitud dice esto:

Si la longitud especificada es mayor que la longitud actual, el final del valor de cadena de esta instancia se rellena con espacios.

Traté de usar StringBuilder con esto en mente, y obtuve resultados extraños. Usé Reflector y vi el problema. La documentación para la propiedad Longitud en .NET 2.0 y versiones posteriores tiene la información correcta:

Si la longitud especificada es mayor que la longitud actual, el final del valor de cadena del objeto StringBuilder actual se rellena con el carácter NULL Unicode (U + 0000).

Esto puede hacer una gran diferencia si, por ejemplo, está mostrando el texto resultante con un cuadro de mensaje; MessageBox corta el texto en el primer carácter nulo.

Reflector permite descubrir cosas como esta, ver cómo se comporta realmente el CLR , a diferencia de lo que dice la documentación, o responder preguntas que la documentación simplemente no responde.

A veces es más simple entender lo que está haciendo una biblioteca, cómo lo está haciendo y usarla de manera apropiada al mirar su código fuente.

Otras veces, simplemente tengo curiosidad y quiero echar un vistazo.

Otra forma común en que uso Reflector es ver cómo el Framework mismo implementa algo.

En ocasiones, tengo una biblioteca en uso en un proyecto muy antiguo y no tenemos ningún código fuente o documentación. Reflector es bastante invaluable en esas situaciones.

También lo he usado para ensamblar parches en caliente. Ha habido algunos casos en los que he necesitado ajustar un bit interno de una biblioteca que no puedo reconstruir y usar Reflector para encontrar el punto apropiado y luego modificar la IL del ensamblado (no, no estoy hablando de grietas, sino de usos legítimos de esta funcionalidad).

No diría que es esencial. Pero en los raros casos en los que realmente lo necesita, es muy útil.

Toma un ejemplo.

Recientemente tuve que crear un fragmento de código que pudiera ejecutar en tiempo de ejecución el árbol de expresiones para lo siguiente, pero sin conocer el nombre de la propiedad dependiente en el momento de la compilación:

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

Para configurar dinámicamente un simulacro (usando el marco Moq).

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

Lo que hice fue compilar la expresión original usando tipos concretos, luego usando reflector, descubrí que tenía que escribir el siguiente 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;    

Hubiera podido resolver esto usando prueba y error. Pero el reflector lo hizo fácil.

Porque si sabe cómo usarlo, no necesita documentación, y la mayoría de las API no tienen ninguna documentación significativa.