Dlaczego reflektor jest tak istotnym narzędziem?

Czytanie płatnej oprawy Reflectora sprawiło, że pomyślałem o produkcie i jego zastosowaniach. Wiele osób uważa to za niezbędne narzędzie.

Muszę przyznać, że nie używałem Odbłyśnika od lat. Mam na myśli, że istnieje dokumentacja zarówno dla interfejsów API .Net, jak i komponentów innych firm, których używam. W przeszłości, gdy kolega wyciągał Odbłyśnik z paska narzędzi, miałem wrażenie, że zmierza w stronę chwastów.

Czytanie całej pasji wokół Reflector prowadzi mnie do pytania, czy naprawdę czegoś tu brakuje. Dlaczego potrzebujesz czegoś takiego jak Odbłyśnik tak często, że uważasz to za niezbędne narzędzie? Widzę, że jest to potrzebne w bardzo rzadkich przypadkach, ale niewystarczająco, aby uznać je za niezbędne narzędzie. Proszę, oświeć mnie.

Oto doskonały przykład typu pytania, na które może odpowiedzieć .NET Reflector.

Lub możesz opublikować to na SO i pozwolić, aby ktoś inny z zainstalowanym Reflector odpowiedział na to za ciebie. ;)

Używam reflektora dość regularnie (może średnio jeden lub dwa razy w tygodniu), aby pomóc w dwóch różnych kwestiach.

1. Źle udokumentowane API / biblioteka: Moim ulubionym przykładem jest SharePoint. Większość programistów, których znam, którzy zajmują się tworzeniem oprogramowania SharePoint, używa go do uzupełniania dostępnej dokumentacji. Czy moglibyśmy sobie bez tego poradzić, w większości tak; ale było wiele przypadków, w których byłoby to raczej trudne.

2. Debugowanie niejasnego błędu: może być również pomocny w ustaleniu, dlaczego coś zgłasza wyjątek. Jeśli widzisz, gdzie wystąpił wyjątek, możesz prześledzić łańcuch połączeń, aby dowiedzieć się, na czym polega problem (niepoprawnie używając biblioteki, błędu itp.).

Odbłyśnik jest niezbędny, gdy masz jakiś zestaw strony trzeciej, którego musisz użyć i jest albo słabo udokumentowany, albo zawiera błędy i chcesz wiedzieć, co się dzieje z jego kodem.

Jasne, wszystko co musisz zrobić, to zaciemnić kod, a Odbłyśnik jest bezużyteczny (lub był to ostatni raz, kiedy sprawdzałem), ale zaoszczędziło mi to dużo czasu i frustracji w przeszłości.

Ponadto miałem co najmniej jedną okazję, kiedy straciłem kod źródłowy (w mojej erze kontroli wersji wcześniejszych), ale skompilowałem kod i Reflektor pomógł mi odzyskać mój kod. Potrzebowałem dużo pracy, ponieważ komentarze, nazwy zmiennych itp. Są błędne, ale pomogło.

Czasami masz też kod w, powiedzmy, VB.NET i chcesz zobaczyć, jak by to było zrobione, powiedzmy, w C # i Reflector może przełączać się między różnymi językami.

Podczas korzystania z Reflection.Emit do generowania zestawów w czasie wykonywania, Reflector staje się niezwykle cennym narzędziem do wizualnej weryfikacji wygenerowanego kodu zgodnie z oczekiwaniami.

Reflektor pomaga wykryć, kiedy dokumentacja jest nieprawidłowa. Znalazłem błąd w dokumentacji StringBuilder CLR już w .NET 1.1. Dokumentacja właściwości Length mówi:

Jeśli określona długość jest większa niż bieżąca długość, wartość końca łańcucha tego wystąpienia jest uzupełniana spacjami.

Próbowałem użyć StringBuilder, mając to na uwadze, i uzyskałem dziwne wyniki. Użyłem reflektora i zobaczyłem problem. Dokumentacja właściwości Length w .NET 2.0 i nowszych zawiera prawidłowe informacje:

Jeśli określona długość jest większa niż bieżąca długość, wartość końca łańcucha bieżącego obiektu StringBuilder jest uzupełniana znakiem Unicode NULL (U + 0000).

Może to mieć duże znaczenie, jeśli, powiedzmy, wyświetlasz wynikowy tekst za pomocą MessageBox; MessageBox odcina tekst od pierwszego pustego znaku.

Odbłyśnik pozwala dowiedzieć się takich rzeczy, zobaczyć, jak naprawdę zachowuje się CLR , w przeciwieństwie do tego, co mówi dokumentacja, lub odpowiedzieć na pytania, na które dokumentacja po prostu nie odpowiada.

Czasami łatwiej jest zrozumieć, co robi biblioteka, jak to robi i odpowiednio go używać, patrząc na kod źródłowy.

Innym razem jestem po prostu ciekawy i chcę zajrzeć.

Innym powszechnym sposobem, w jaki używam Reflector, jest sprawdzenie, jak sam Framework implementuje coś.

Czasami mam bibliotekę używaną w naprawdę starym projekcie i nie mamy żadnego kodu źródłowego ani dokumentacji. W takich sytuacjach reflektor jest bardzo nieoceniony.

Użyłem go również do poprawiania zespołów. Było kilka przypadków, w których musiałem ulepszyć wewnętrzny kawałek biblioteki, którego nie mogę odbudować i używając Odbłyśnika, aby znaleźć odpowiedni punkt, a następnie zmodyfikować IL zespołu (nie, nie mówię o łamaniu, ale uzasadnionym użyciu ta funkcjonalność).

Nie powiedziałbym, że jest to niezbędne. Ale w rzadkich przypadkach, gdy naprawdę tego potrzebujesz, jest to bardzo przydatne.

Brać przykład.

Ostatnio musiałem utworzyć kawałek kodu, który mógłby w czasie wykonywania utworzyć drzewo wyrażeń dla następujących elementów, ale nie znając nazwy właściwości zależnej w czasie kompilacji:

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

W celu dynamicznego skonfigurowania makiety (przy użyciu frameworku Moq).

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

Zrobiłem to, że skompilowałem oryginalne wyrażenie przy użyciu konkretnych typów, a następnie używając reflektora, okazało się, że muszę napisać następujący kod:

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;    

Byłbym w stanie to rozgryźć na podstawie prób i błędów. Ale reflektor to ułatwił.

Ponieważ jeśli wiesz, jak go używać, nie potrzebujesz dokumentacji - a większość interfejsów API nie ma żadnej sensownej dokumentacji.