Почему Reflector такая важная утилита?

Чтение суеты вокруг «Рефлектора», платного, заставило меня задуматься о продукте и его использовании. Многие люди считают это важным инструментом.

Я должен признать, я не использовал Reflector в течение многих лет. Я имею в виду, что есть документация для API .Net и сторонних компонентов, которые я использую. В прошлом, когда коллега вытаскивал Reflector из своего пояса с инструментами, я чувствовал, что он направляется в сорняки.

Чтение всей страсти вокруг Reflector заставляет меня задаться вопросом, действительно ли я что-то здесь упускаю. Зачем вам что-то вроде Reflector так часто, что вы считаете это важным инструментом? Я вижу, что это необходимо в очень редких случаях, но недостаточно, чтобы считаться важным инструментом. Пожалуйста, просветите меня.

Вот прекрасный пример вопроса такого типа .NET Reflector может ответить за вас.

Или вы можете опубликовать его на SO, и пусть кто-нибудь другой с установленным Reflector ответит за вас. ;)

Я использую отражатель довольно регулярно (может быть, один или два раза в неделю в среднем), чтобы помочь с двумя различными проблемами.

1. Плохо документированный API / библиотека. Мой любимый пример для этого - SharePoint. Большинство разработчиков, которые я знаю о разработке SharePoint, используют ее для дополнения доступной документации. Можем ли мы обойтись без этого, по большей части да; но было много случаев, когда это было бы довольно сложно.

2. Отладка неясной ошибки: это также может быть полезно для выяснения, почему что-то вызывает исключение. Если вы видите, где произошло исключение, вы можете отследить цепочку вызовов, чтобы выяснить, в чем проблема (либо неправильно использовать библиотеку, ошибку и т. Д.).

Reflector необходим, когда у вас есть какая-то сторонняя сборка, которую вы должны использовать, и она либо плохо документирована, либо содержит ошибки, и вы хотите знать, что происходит с ее кодом.

Конечно, все, что вам нужно сделать, это запутать ваш код, и Reflector бесполезен (или это было в прошлый раз, когда я проверял), но это сэкономило мне много времени и разочарований в прошлом.

Кроме того, у меня был, по крайней мере, один случай, когда я потерял исходный код (в мою эру до контроля версий), но скомпилированный код и Reflector помогли мне вернуть мой код. Требовалось много работы, потому что комментарии, имена переменных и т. Д. Неверны, но это помогло.

Кроме того, иногда у вас есть код, скажем, в VB.NET, и вы хотите посмотреть, как это будет, скажем, в C # и Reflector может переключаться между различными языками.

При использовании Reflection.Emit для генерации сборок во время выполнения Reflector становится чрезвычайно полезным инструментом для визуальной проверки сгенерированного кода, как вы и ожидаете.

Reflector поможет вам обнаружить, когда документация неверна. Я обнаружил ошибку в документации CLR StringBuilder еще в .NET 1.1. Документация для свойства Length говорит следующее:

Если указанная длина больше текущей длины, конец строкового значения этого экземпляра дополняется пробелами.

Я попытался использовать StringBuilder с учетом этого и получил странные результаты. Я использовал Reflector, и увидел проблему. Документация для свойства Length в .NET 2.0 и более поздних версиях содержит правильную информацию:

Если указанная длина больше текущей длины, конец строкового значения текущего объекта StringBuilder дополняется символом Unicode NULL (U + 0000).

Это может иметь большое значение, если, скажем, вы отображаете полученный текст с помощью MessageBox; MessageBox обрезает текст с первым нулевым символом.

Reflector позволяет выяснить подобные вещи, увидеть, как на самом деле ведет себя CLR , в отличие от того, что говорится в документации, или ответить на вопросы, на которые документация просто не отвечает.

Иногда проще понять, что делает библиотека, как она это делает, и правильно использовать ее, посмотрев на ее исходный код.

В другое время мне просто любопытно и хочется заглянуть.

Еще один распространенный способ использования Reflector - это посмотреть, как сама Framework реализует что-то.

Иногда я использую библиотеку в очень старом проекте, и у нас нет исходного кода или документации. Отражатель весьма неоценим в этих ситуациях.

Я также использовал его для сборки патчей. Было несколько случаев, когда мне нужно было настроить внутреннюю часть библиотеки, которую я не могу перестроить, и использовать Reflector, чтобы найти подходящую точку, а затем изменить IL сборки (нет, я не говорю о взломе, но о законном использовании это функциональность).

Я бы не сказал, что это существенно. Но в тех редких случаях, когда это действительно нужно, это очень полезно.

Возьми пример.

Недавно мне пришлось создать некоторый фрагмент кода, который мог бы во время выполнения создать дерево выражений для следующего, но не зная имени зависимого свойства во время компиляции:

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

Для того, чтобы динамически настроить макет (используя инфраструктуру Moq).

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

Что я сделал, так это то, что я скомпилировал исходное выражение с использованием конкретных типов, а затем с помощью рефлектора. Я обнаружил, что мне нужно написать следующий код:

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;    

Я был бы в состоянии понять это, используя метод проб и ошибок. Но отражатель сделал это легко.

Потому что, если вы знаете, как его использовать, вам не нужна документация - и большинство API не имеют какой-либо значимой документации.