問題タブ [methodinfo]

ここに同様の質問があります：

C# を使用してメソッドをパラメーターとして渡す

メソッドの引数と戻り値の型を知っていることを前提としています。少し違うことをしたいと思います。代わりにラムダ関数を取る System.Reflection の .GetMethod(string) のバージョンを作成しようとしています-その代わりに:

よりコンパイルセーフなものを使用できます：

したがって、ReflectionHelper が引数の数と戻り値の型を事前に知っていれば、答えは単純なものになります。たとえば、引数がなく、文字列が返される場合:

引数のカウント/戻り値の型が事前にわからないことを除いて、すべてのケースではなくほとんどのケースをカバーする 20 のオーバーロードでスパムするのは避けたいと思います。

それで、どうすればいいですか？

どのプロジェクトにもアタッチ可能でなければならない dll ライブラリを作成していますが、解決できないことが 1 つあります。

dll ファイルから MethodInfo を呼び出し/実行する必要があります。そして、それはこのように見えます。SenderMethod、args と同じであり、カウントは動的です。

問題は、GetType が何も返さないことです。そこにアセンブリ名がないことは知っていますが、呼び出し元クラスが静的ではない状況に適用できる解決策を見つけることができませんでした。

助けてください！ありがとうございました！

私は一般的な方法を持っています

ユーザーがイベントに登録し、このデリゲートを提供できるようにします。タイプに応じてデリゲートのリストを保存する必要があります。

タイプとオブジェクトの辞書に保存してみました。メソッドを追加するとき、私はそれをにキャストします

Tによると、しかし、イベントが発生したとき、私はTを持っていないので、ジェネリックハンドラーの関連リストにキャストできません（私はタイプを持っていますが、Tは持っていません）

タイプごとにmethodInfoリストを保存することでこれを解決しました

ただし、問題は、このアプローチが静的な場合にのみ機能することです。そうでない場合は、クラスの型が必要になります。

この問題の解決策はありますか？

一般的なイベントを有効にします...ありがとう！

私は DRY コーディングの大ファンで、定型コードはできるだけ避けたいと思っています。したがって、すべての WCF チャネル faff を、WCF チャネルのライフサイクルを処理する AOP クラスにリファクタリングしました。

また、私は async-await の大ファンでもあり、特に WCF では、通常はスリープ状態で応答を待機しているスレッドを理論的に解放できるためです。

そこで、fluentAOP lib にインターセプターを作成しました

ただし、解決策について少し考えてみると、フォームの WCF コントラクトの場合、

GetInt は予期しない結果をもたらします。まず、catch FaultException は何もしません。次に、リクエストが返される前にチャネルを閉じます。戻り値の型が Task の場合、理論的には別のコード パスに切り替えることができます。しかし、Task<> の結果を待ってから awaitable を返す方法がわかりません。

もちろん、これは特に困難です。なぜなら、ランタイム AOP を使用すると、戻り値の型のジェネリックを使用できるアクセス権がないからです (リフレクションの全体がなければ)。

この関数を awaitable として実装する方法はありますか?完了時にチャネルを閉じ、呼び出しスレッドへの例外をキャッチ/マーシャリングしますか?

Action デリゲートに渡されたメソッド名を取得しようとしています。これは私が持っているものです:

そして主に、これはそれがどのように呼び出されるかです:

DoAction() メソッドの実行後、画面に「DoFoo」と「DoBar」が表示されることを望んでいましたが、代わりに <Main>b__0と<Main>b__1. アクションデリゲートからターゲットメソッドの実際の名前を取得する方法があるかどうか疑問に思っていましたか? どんな助けでも大歓迎です。

拡張メソッドを書きましたGenericExtension。次に、拡張メソッドを呼び出しますExtension。ただし、の値methodInfoは常に null です。

どうしたの？

これは、この質問へのフォローアップです:ラムダ式が期待される MemberInfo を返さない

sについても同様MethodInfoです。

Humanがインターフェースである場合とname、Humanが抽象/仮想である場合の違いが必要であることは理解できます。しかし、なぜ密閉型の場合はそうなるのでしょうか? のは正確にはnameのではありませんか?MannameHuman

明確化: Jon が言うように、彼らReflectedTypeの s は異なります。ReflectedTypein equality は、インターフェイス メンバーまたはオーバーライドされたメンバーが異なるため、それらが等しいかどうかを判断するときに便利です。しかし、上記のような単純なケースの同等性を判断するために考慮する必要はないと思います。設計チームは一貫性を保ちたかったのかもしれません。ReflectedType複数のクラスにまたがる同じメンバーの等価性を決定する際に、フレームワーク設計者がプロパティを考慮するようになった理由は何なのか疑問に思っています。

MethodInfo任意の署名を持つ非ジェネリックな静的メソッドを表すインスタンスを受け取り、メソッドを使用して後で呼び出すことができるそのメソッドにバインドされたデリゲートを返すメソッドが必要Delegate.DynamicInvokeです。私の最初の素朴な試みは次のようになりました：

MethodInfo.CreateDelegateメソッドが正しいデリゲート型自体を把握できることを願っていました。まあ、明らかにそれはできません。System.Typeでは、提供されたインスタンスと一致する署名を持つデリゲートを表すインスタンスを作成するにはどうすればよいMethodInfoでしょうか?

リフレクションを使用して、メソッドの例外処理ブロックをクラスの[ExceptionHandlingClauses]プロパティで分析しています。このコレクションがどのように動作し、どのように解釈するか、 MSDN ドキュメント[MethodBody]からはわかりませんでした。それを主張したいとしましょう：

• メソッドには、try ブロックが 1 つだけ含まれています。
• その単一のブロックには、ちょうど 1 つのcatch句が含まれます。
• その単一のブロックにはfinally句が含まれています。

ここで説明するには複雑すぎるため、次のコードからコンテキストを導き出さないようにしてください。これは単なる例示的なコードであり、設計が悪い可能性があります。次の階層を考えてみましょう。

私はこれらのクラスについて次のことをすでに知っています。

• Tier 1 基本クラスには実装がないため、例外処理ブロックはありません。
• 層 2 の派生クラスには実装がないため、例外処理ブロックはありません。
• 層 3 の派生クラスには、すべての仮想メソッドの実装があり[OnTest]、例外処理ブロックを除くすべてのメソッドには含まれません。
• すべての Tier 3 クラスの[OnTest]メソッドには、例外処理ブロックが 1 つだけ含まれており、場合によっては、ネストされたブロックやいくつかの[using]ステートメントが含まれています。

このアセンブリから層 3 のすべてのクラスを取得し、各型を反復処理して、[MethodInfo]各メソッドのオブジェクトを取得し、オブジェクトを取得してそのコレクション[MethodBody]を調べます。[ExceptionHandlingClauses]メソッドの結果は非常に奇妙です[OnTest]。コレクションには0 ～ 6 個の節があり、それぞれが または のいずれかの値[ExceptionHandlingClauses]を持っています。予想されるブロック数とこのコレクションが示すものとの間には、まったく相関関係がないようです。[Flag][Catch][Finally][catch/finally]

場合によっては、ブロック[Finally]さえも持たないメソッドに 2 つの句が表示されることがあります。[try/catch]

最初は、これは継承と関係があるのではないかと思っていましたが、例外処理ブロックは言うまでもなく、どの基本クラスにも実装がありません。

いくつかのガイダンスをいただければ幸いです。