问题标签 [methodinfo]

这里有一个类似的问题：

使用 C# 将方法作为参数传递

假设您知道方法的参数和返回类型。我想做点不一样的。我正在寻找创建 System.Reflection 的 .GetMethod(string) 的一个版本，它采用 lambda 函数 - 所以而不是：

我可以使用更安全的编译：

因此，如果 ReflectionHelper 事先知道参数计数和返回类型，那么答案将很简单——例如，如果它没有参数并返回字符串：

除了我事先不知道参数计数/返回类型，我想避免只是用 20 个覆盖大多数但不是所有情况的重载来发送垃圾邮件。

那么，我该怎么做呢？

我正在编写一个必须可附加到任何项目的 dll 库，但有一件事我无法解决。

我需要从 dll 文件调用/运行 MethodInfo。它看起来像这样。SenderMethod，与 args 相同，计数是动态的。

问题是 GetType 什么都不返回。我知道那里缺少组件名称，但是我找不到适用于调用者类不是静态的情况的解决方案。

请帮忙！谢谢！

我有一个通用方法

我使用户能够注册事件并提供此委托。我需要根据他们的类型保存委托列表。

我尝试保存在类型和对象的字典中。添加方法时，我将其转换为

根据 T. 但是当事件发生时我没有 T 所以不能转换到相关的通用处理程序列表（我有 Type 但没有 T）

我通过为每种类型保存 methodInfo 列表来解决这个问题

但问题是这种方法只有在方法是 static 时才有效，否则它将需要类的类型。

这个问题有解决办法吗？？？

启用通用事件...谢谢！

我有MethodInfo一个类类型的方法，它是该类实现的接口定义的一部分。
如何MethodInfo在类实现的接口类型上检索方法的匹配对象？

我是 DRY 编码的忠实粉丝，我喜欢尽可能避免使用样板代码。因此，我将我所有的 WCF 通道 faff 重构为一个 AOP 类，它处理 WCF 通道的生命周期。

我也是 async-await 的忠实粉丝，尤其是 WCF，因为理论上它会释放一个通常会休眠等待响应的线程。

所以我在fluentAOP lib中创建了一个拦截器

但是，在考虑一下解决方案时，我注意到在 WCF 合同形式的情况下

GetInt 会产生意想不到的结果。首先，catch FaultException 什么都不做。其次，我会在请求返回之前关闭通道。如果返回类型是任务，我理论上可以切换到另一个代码路径。但我不知道如何等待 Task<> 的结果，然后返回一个可等待的。

这当然特别困难，因为使用运行时 AOP，我将无法使用返回类型的泛型（没有整个反射范围）。

任何想法如何将此函数实现为可等待的，它在完成时关闭通道并捕获/编组调用线程的异常？

我正在尝试将方法名称传递给 Action 委托。这就是我所拥有的：

总的来说，这就是它的调用方式：

执行 DoAction() 方法后，我希望在屏幕上看到“DoFoo”和“DoBar”，但我看到的是 <Main>b__0和<Main>b__1. 我只是想知道是否有办法从动作委托中获取目标方法的实际名称？任何帮助表示赞赏。

我写了扩展方法GenericExtension。现在我想调用扩展方法Extension。但 的值methodInfo始终为空。

怎么了？

这是这个问题的后续：Lambda 表达式没有返回预期的 MemberInfo

s也是MethodInfo如此。

Human我可以理解什么时候是接口，或者什么时候name是Human抽象/虚拟的，必须有所不同。但是为什么密封类型会如此呢？不正是nameof吗？MannameHuman

澄清：正如乔恩所说，他们ReflectedType的 s 是不同的。ReflectedType在决定接口成员或被覆盖成员的相等性时，在相等性应该派上用场，因为它们是不同的。但我认为不应该考虑决定上述简单案例的平等性。可能是设计团队想要保持一致。只是想知道是什么原理促使框架设计人员ReflectedType在决定跨多个类的同一成员的相等性时考虑属性。

我需要一个方法，它接受一个MethodInfo表示具有任意签名的非泛型静态方法的实例，并返回一个绑定到该方法的委托，该方法以后可以使用Delegate.DynamicInvoke方法调用。我的第一次天真的尝试是这样的：

我希望该MethodInfo.CreateDelegate方法本身可以找出正确的委托类型。好吧，显然它不能。那么，如何创建一个System.Type代表具有与提供的实例匹配的签名的委托的MethodInfo实例？

I am using reflection to analyse a method's exception handling blocks with the [ExceptionHandlingClauses] property of the [MethodBody] class. I could not figure out from MSDN Documentation how this collection behaves and how to interpret it. Let's say you want to assert that:

• a method contains exactly one try block.
• that single block contains exactly one catch clause.
• that single block contains a finally clause.

Please try not to derive context out of the following code as it is too complex to explain here. This is just illustrative code and may be of bad design. Consider the following heirarchy:

I already know the following about these classes:

• Tier 1 base class has no implementation, thus no exception handling blocks.
• Tier 2 derived classes have no implementation, thus no exception handling blocks.
• Tier 3 derived classes have implementations of all virtual methods where all methods except [OnTest] do NOT contain exception handling blocks.
• The [OnTest] method of all Tier 3 classes contains exactly one exception handling block and in some cases a nested block and/or a few [using] statements.

I get all tier 3 classes from this assembly, iterate through each type, get the [MethodInfo] objects for each method, get the [MethodBody] object and inspect its [ExceptionHandlingClauses] collection. The result is quite strange for the [OnTest] method. The [ExceptionHandlingClauses] collection shows up having anywhere between 0 to 6 clauses, each of which has a [Flag] value of either [Catch] or [Finally]. There seems to be absolutely no correlation between the expected number of [catch/finally] blocks and what this collection shows.

Sometimes, it evens shows two [Finally] clauses in methods which do not even have a [try/catch] block.

At first I thought this may have something to with inheritance but none of the base classes have implementations, let alone exception handling blocks.

Some guidance would be appreciated.