MethodBase.GetCurrentMethod 何时可靠/可预测？

Question

方法可以内联；有一个属性可以防止这种情况（“有一个 att ”）。然而，显然，由于 JITter 的尾部调用优化，方法也可能无法在 x64 上获得自己的堆栈帧（http://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInlinedInReleaseBuildCallStacks.aspx）。这会影响 MethodBase.GetCurrentMethod 的行为吗？

我能找到的讨论主要是关于内联的（什么时候方法可以被 CLR 内联？）。虽然这些讨论本身很有趣，但我的问题实际上是在什么情况下（如果有的话）可以依赖 MethodBase.GetCurrentMethod 来识别程序员调用的相同方法（例如，对于后期绑定到当前方法实际上是代理的方法）。内联是一种可以欺骗 MethodBase.GetCurrentMethod 的方法，但我想知道这是否是唯一的方法？

Answer 1

否 - 方法要么在运行时内联，要么不内联。

我相信，如果有人要实现自己的运行时，它可能会被愚弄 - 因为 MethodBase.GetCurrentMethod 最终归结为在 RuntimeMethodHandle 中声明的：

[SecurityCritical]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern IRuntimeMethodInfo 
  _GetCurrentMethod(ref StackCrawlMark stackMark);

在自定义运行时中，它可以做任何事情 - 将来它也可以做任何事情。目前，我认为 Microsoft 运行时不会返回正确方法的唯一方法是内联代码；例如，不能代表 Mono。然而，我认为，始终依赖这种情况就像依赖始终存在的内部类型的反射私有字段来使一段代码能够工作一样。

在几乎所有我尝试过的情况下（我现在不再担心它）或者有人试图证明需要能够可靠地识别调用方法，除了分析之外，内联方法的问题总是会出现。

但现实是，担心这些方法有多重要？

如果可靠性绝对至关重要，那么您会更幸运 使用 IL 重写器后编译来注入日志记录调用；这可能必然是方法感知的，因此可能会破坏内联，即使它发生了（如果重写的 IL 变得足够大，从而损害性能，则可能不会）。或者，如果您不喜欢自己开发，可以使用 AOP 库 - 例如 PostSharp。