Чому Reflector є такою необхідною утилітою?

Читання brouhaha навколо Reflector буде платним, я задумався про продукт та його використання. Багато людей, здається, вважають це важливим інструментом.

Треба визнати, що Reflector я не використовував уже роки. Я маю на увазі, є документація як для API API .Net, так і для сторонніх компонентів, які я використовую. У минулому, коли кожен колега витягував рефлектор зі свого інструментального поясу, я відчував, що він прямує до бур'янів.

Читання всієї пристрасті навколо Reflector приводить мене до питання, чи справді я чогось тут пропускаю. Чому вам потрібне щось на зразок Reflector так часто, що ви вважаєте це важливим інструментом? Я можу бачити, що це потрібно в дуже рідкісних випадках, але недостатньо, щоб вважати його важливим інструментом. Будь ласка, просвіти мене.

Ось ідеальний приклад типу запитання .NET Reflector може відповісти за вас.

Або ви можете опублікувати його на SO та дозволити комусь іншому зі встановленим Reflector відповісти на нього. ;)

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

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

2. Налагодження незрозумілої помилки: вона також може бути корисною для з'ясування того, чому щось кидає виняток. Якщо ви бачите, де сталася виняток, ви можете відстежити назад ланцюжок викликів, щоб з’ясувати, у чому проблема (або неправильно, використовуючи бібліотеку, помилку тощо).

Reflector є важливим, коли у вас є якась стороння збірка, яку ви повинні використовувати, і вона погано документована, або в ній є помилки, і ви хочете знати, що відбувається з її кодом.

Звичайно, все, що вам потрібно зробити, це придушити свій код, і Reflector марний (або це я востаннє перевіряв), але це врятувало мені багато часу і розчарувань у минулому.

Крім того, у мене був принаймні один випадок, коли я втратив вихідний код (в епоху контролю перед версією), але мені складений код і Reflector допомогли мені повернути свій код. Потрібно багато роботи, оскільки коментарі, назви змінних тощо неправильні, але це допомогло.

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

Використовуючи Reflection.Emit для генерації збірок під час виконання, Reflector стає надзвичайно цінним інструментом для візуальної перевірки згенерованого коду, як ви очікували.

Reflector допоможе вам виявити, коли документація неправильна. Я знайшов помилку в документації StringBuilder CLR ще в .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 не мають жодної змістовної документації.