Reflectorがなぜこのような重要なユーティリティなのですか？

リフレクターを取り巻く問題を読んで、私は製品とその使用法について考えました。多くの人々はそれを必須のツールと考えているようです。

私は認めざるを得ません、私は何年もリフレクターを使用していません。つまり、.Net APIと使用するサードパーティコンポーネントの両方のドキュメントがあります。以前は、同僚がリフレクターをツールベルトから引き抜いたときはいつでも、彼が雑草に向かったという感覚を得ました。

Reflectorに関する情熱をすべて読んでいると、本当に何かが足りないのかと疑問に思うようになります。リフレクターのようなものが非常に頻繁に必要になるので、それを不可欠なツールと考えるのはなぜですか？非常にまれに必要になる場合もありますが、必須のツールと見なすには不十分です。教えてください。

ここだ完璧な例 .NETリフレクターがあなたのために答えることができる質問の種類の。

または、SOに投稿して、Reflectorがインストールされている他の人に答えてもらうこともできます。;）

私は2つの異なる問題を解決するために、かなり定期的に（平均して週に1〜2回）リフレクターを使用しています。

1. 不十分に文書化されたAPI /ライブラリ：これの私のお気に入りの例はSharePointです。私が知っているSharePoint開発のほとんどすべての開発者は、利用可能なドキュメントを補足するためにそれを使用しています。それがなくても、ほとんどの場合はい。しかし、かなり困難だったと思われる場合がいくつかあります。

2. あいまいなエラーのデバッグ：何かが例外をスローしている理由を解明するのにも役立ちます。例外が発生した場所を確認できる場合は、コールチェーンをトレースして、問題が何であるかを理解できます（ライブラリやバグなどを誤って使用しています）。

リフレクターは、使用する必要のあるサードパーティのアセンブリがあり、ドキュメントが不十分であるか、バグがあり、コードで何が行われているのかを知りたい場合に不可欠です。

確かに、あなたがしなければならないことはコードを難読化することであり、Reflectorは役に立たない（または前回チェックしたときだった）が、それによって過去の多くの時間とフラストレーションを節約できた。

また、（以前のバージョン管理時代に）ソースコードを失ったことはありますが、コンパイルされたコードとReflectorを使用してコードを元に戻すことができました。コメント、変数名などが間違っているため、多くの作業が必要でしたが、役に立ちました。

また、VB.NETなどにコードがあり、C＃やReflectorでさまざまな言語に切り替える方法を確認したい場合もあります。

実行時にアセンブリを生成するためにReflection.Emitを使用する場合、Reflectorは、生成されたコードが期待どおりであることを視覚的に確認するための非常に貴重なツールになります。

Reflectorは、ドキュメントが間違っている場合に発見するのに役立ちます。.NET 1.1に戻ったときに、CLRのStringBuilderドキュメントにバグが見つかりました。Lengthプロパティのドキュメントはこれを言っています：

指定された長さが現在の長さより大きい場合、このインスタンスの文字列値の終わりはスペースで埋められます。

これを念頭に置いてStringBuilderを使用しようとすると、奇妙な結果が得られました。リフレクターを使ってみましたが、問題がありました。.NET 2.0以降のLengthプロパティのドキュメントには、正しい情報が記載されています。

指定された長さが現在の長さよりも長い場合、現在のStringBuilderオブジェクトの文字列値の終わりには、Unicode NULL文字（U + 0000）が埋め込まれます。

たとえば、メッセージボックスで結果のテキストを表示している場合、これは大きな違いを生む可能性があります。MessageBoxは、最初のnull文字でテキストを切り取ります。

Reflectorを使用すると、このようなことを見つけたり、ドキュメントの内容とは対照的にCLRの実際の動作を確認したり、ドキュメントが答えていない質問に答えたりすることができます。

ライブラリが何をしているか、どのようにしているかを理解し、ソースコードを見て適切に使用する方が簡単な場合があります。

また、私は単に好奇心が強いので、のぞきたいです。

私がリフレクターを使用するもう1つの一般的な方法は、フレームワーク自体が何かを実装する方法を確認することです。

時々、本当に古いプロジェクトで使用されているライブラリがあり、ソースコードやドキュメントがありません。そのような状況では、リフレクターは非常に貴重です。

また、アセンブリのホットパッチにも使用しました。再構築できないライブラリの内部ビットを微調整し、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には意味のあるドキュメントがありません。