Reflector neden bu kadar önemli bir yardımcı programdır?

Reflektör'ü çevreleyen brouhahaları okumak, ürün ve kullanımları hakkında düşünmemi sağladı. Birçok insan bunu önemli bir araç olarak görüyor.

İtiraf etmeliyim, yıllardır Reflektör kullanmadım. Yani, .Net API'leri ve kullandığım üçüncü taraf bileşenler için belgeler var. Geçmişte, bir meslektaşınız Reflector'u alet kemerinden çıkardığında, yabani otlara yöneldiğini anladım.

Reflector etrafındaki tüm tutkuyu okumak beni burada gerçekten bir şey eksik olup olmadığımı sorgulamaya yönlendiriyor. Neden Reflektör gibi bir şeye ihtiyacınız var ki, onu önemli bir araç olarak görüyorsunuz? Çok nadir durumlarda gerekli olduğunu görebiliyorum, ancak önemli bir araç olarak görülmek için yeterli değil. Lütfen beni aydınlat.

İşte .NET Reflector'un sizin için cevaplayabileceği soru türüne mükemmel bir örnek .

Ya da SO'ya gönderebilir ve Reflector yüklü başka birinin sizin için cevaplamasına izin verebilirsiniz. ;)

İki farklı konuda yardımcı olması için reflektörü oldukça düzenli olarak (belki haftada bir veya iki kez) kullanıyorum.

1. Belgelenmemiş API / Kütüphane: Buna en sevdiğim örnek SharePoint. SharePoint geliştirme yaparken bildiğim çoğu geliştirici bunu mevcut belgeleri desteklemek için kullanıyor. Onsuz halledebilir miyiz, çoğunlukla evet; ama oldukça zor olsaydı bir takım davalar oldu.

2. Belirsiz bir hata ayıklama: Bir şeyin neden bir istisna oluşturduğunu bulmakta da yararlı olabilir. İstisnanın nerede oluştuğunu görebiliyorsanız, sorunun ne olduğunu (yanlış bir kütüphane, hata vb. Kullanarak) bulmak için çağrı zincirini geri izleyebilirsiniz.

Reflektör, kullanmanız gereken bazı üçüncü taraf montajlarınız olduğunda ve kötü belgelenmiş veya içinde hatalar olduğunda ve koduyla neler olduğunu bilmek istediğinizde gereklidir.

Tabii, tek yapmanız gereken kodunuzu gizlemek ve Reflektör işe yaramaz (veya son kontrol ettiğim zaman) ama geçmişte bana çok fazla zaman ve hayal kırıklığı kurtardı.

Ayrıca, kaynak kodunu (sürüm öncesi kontrol çağımda) kaybettim ama derlenmiş kod ve Reflector kodumu geri almama yardımcı oldu en az bir kez yaşadım. Yorumlar, değişken isimleri vb. Yanlış olduğu için çok çalışmak gerekiyordu ama yardımcı oldu.

Ayrıca, bazen VB.NET'te kodunuz vardır ve bunun nasıl yapılacağını görmek istersiniz, örneğin, C # ve Reflektör çeşitli diller arasında geçiş yapabilir.

Reflection.Emit'i kullanırken çalışma zamanında derlemeler oluşturmak için Reflector, oluşturulan kodu beklediğiniz gibi görsel olarak doğrulamak için son derece değerli bir araç haline gelir.

Reflektör, belgelerin ne zaman yanlış olduğunu keşfetmenize yardımcı olur. .NET 1.1'de CLR'nin StringBuilder belgelerinde bir hata buldum. Length özelliğinin belgeleri şunları söyledi:

Belirtilen uzunluk geçerli uzunluktan büyükse, bu örneğin dize değerinin sonu boşluklarla doldurulur.

StringBuilder'ı bu düşünceyle kullanmaya çalıştım ve tuhaf sonuçlar aldım. Reflektör kullandım ve sorunu gördüm. .NET 2.0 ve sonraki sürümlerde Length özelliğinin belgeleri doğru bilgilere sahiptir:

Belirtilen uzunluk geçerli uzunluktan büyükse, geçerli StringBuilder nesnesinin dize değerinin sonu Unicode NULL karakteriyle (U + 0000) doldurulur.

Sonuçta ortaya çıkan metni bir MessageBox ile görüntülüyorsanız, bu büyük bir fark yaratabilir; MessageBox ilk boş karakterdeki metni keser.

Reflektör, bunun gibi şeyleri bulmayı , belgelerin söylediklerinin aksine CLR'nin gerçekte nasıl davrandığını görmeyi veya belgelerin cevap vermediği soruları yanıtlamayı mümkün kılar .

Bazen bir kütüphanenin ne yaptığını, nasıl yaptığını anlamak ve kaynak koduna bakarak uygun şekilde kullanmak daha kolaydır.

Diğer zamanlarda, sadece merak ediyorum ve bakmak istiyorum.

Reflektörü kullanmanın bir diğer yaygın yolu da Çerçevenin kendisinin bir şeyi nasıl uyguladığını görmektir.

Bazen, gerçekten eski bir projede kullanılan bir kütüphanem var ve herhangi bir kaynak kodu ya da dokümanımız yok. Reflektör bu durumlarda oldukça paha biçilmezdir.

Ayrıca sıcak yama montajlarında da kullandım. Bir kütüphanenin dahili bir kısmını değiştirmem gereken birkaç durum vardı ve uygun noktayı bulmak ve daha sonra montajın IL'sini değiştirmek için Reflector'u kullanıyorum (hayır, çatlama hakkında değil, meşru kullanımları hakkında konuşuyorum) bu işlev).

Bunun gerekli olduğunu söylemem. Ancak gerçekten ihtiyaç duyduğunuz nadir durumlarda, son derece yararlıdır.

Bir örnek ver.

Son zamanlarda çalışma zamanı aşağıdaki için ifade ağacı oluşturabilir, ancak derleme zamanında bağımlı özellik adını bilmeden bazı kod parçası oluşturmak zorunda kaldı:

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

Dinamik olarak bir mock kurmak için (Moq framework kullanarak).

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

Yaptığım şey, orijinal ifadeyi somut türleri kullanarak derledim, daha sonra reflektör kullanarak, aşağıdaki kodu yazmak zorunda olduğumu öğrendim:

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;    

Deneme yanılma yöntemiyle bunu anlayabilirdim. Ancak reflektör bunu kolaylaştırdı.

Çünkü nasıl kullanılacağını biliyorsanız, belgelere ihtiyacınız yoktur - ve çoğu API'nin anlamlı belgeleri yoktur.