Tl;dr. 少なくとも私が理解しているように、リフレクションを使用して問題を解決することはできず、それ以上の具体性がなければ..
メソッド解決規則は、特にジェネリック メソッドの場合、非常に複雑です。あなたが陥る多くの落とし穴があります。メソッド、型パラメーターだけでなく、ターゲットに関する多くの情報と、それ自体の型パラメーターも知っておく必要があります。場合によっては、メソッドが から呼び出されました。
- メソッドは基本クラスに実装されていますが、子によって隠されています。
- メソッドはインターフェイスからのものであり、明示的に実装されており、実装者に同じ名前の別のメソッドがある場合があります。
Foo<T>(T a, string other)
、Foo<T>(string a, T other)
、およびその他のいくつかのバリエーションなどのメソッドは、呼び出し元が分からない限りFoo<T>(string a, string other)
明確にすることはできません(これらは正当なメソッドであり、呼び出されるメソッドはいくつかの要因に依存します)。T = string
- メソッドに一般的な制約を設定できます。
- インターフェイスとデリゲートの一般的な分散を含む、引数の型のポリモーフィズム。
- オプションのパラメーター。
- これは延々と続く。
基本的に、それは決して機能しません。リフレクションを使用していません。あなたが提案している方法ではありません。発信できる通話に制限がある場合でも、チェックする項目とチェックしない項目を決定する必要があり、常にいくつかの項目を見逃すことになります。ちなみに、落とし穴はこれらだけではなく、ランダム サンプリングです。
ただし、いくつかのオプションがあります。
私の意見では、最初の、そして最良の選択肢は、一歩下がって元の問題について考えることです。できればそれを投稿してください。それは別の答えを持っているかもしれません、そして人々はあなたにもっと良いアドバイスをすることができるでしょう. うまくいけば、理解するのがそれほど複雑ではありません。
一般的な制約がない、インターフェイスがないなど、問題の範囲を大幅に制限した場合、これが可能になる可能性があります。多くの落とし穴があるため、エラーが発生しやすくなります。
動的バインディングを使用して実行時に解決を試みることはできますが、動的バインディングがメソッドを解決する方法は、通常の方法とは異なる場合があります。私はこれについてあまり知りません。
ランタイムをフックし、解決されたメソッド呼び出しを調査することもできます。これにはライブラリがあります。これにより、遅延バインディングがどのように解決されるかを理解することさえできます。
最後に、IL を調べることができます。これには、さまざまなツールやMono.Cecil
. ビルドされたライブラリでは、メソッドの解決が既に実行されているため、どのメソッドがどの場所から呼び出されているかを正確に確認できます。ただし、これは実現可能ではないようです。
ああ、Roslyn や、インターフェイスを備えた他のコンパイラがあります。すでに解決ロジックが実装されているため、タスクが簡単になる場合があります。それらがオープンソースである場合、そこでメソッド解決がどのように実行されるかを理解しようとすることができます。しかし、私はここで私の深みから外れています。そして、それは実現不可能だと思います。
特定のライブラリへのリンクを投稿するのは好きではありません。また、選択肢が多いからです。
要約すると、少なくとも私の意見では、そして私が問題を理解しているように、方法とより多くの情報に大きな制限がなければ、それは不可能です.