一种方法可以内联;有一个属性可以防止这种情况（“那里有一个att”）。但是，由于JITter（http://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx）的尾调用优化，显然一个方法也可能无法在x64上获得自己的堆栈帧。这会影响MethodBase.GetCurrentMethod的行为吗？
我能找到的讨论主要是关于内联（When is a method eligible to be inlined by the CLR?）。虽然这些讨论本身就很有趣，但我的问题实际上是在什么情况下 - 如果有的话 - MethodBase.GetCurrentMethod可以依赖于识别程序员拨打电话的同一方法（例如，绑定到当前方法实际上是代理的方法）。内联是MethodBase.GetCurrentMethod被愚弄的一种方式，但我想知道这是否是唯一的方法？
答案 0 :(得分：2)
否 - 方法在运行时内联或不是内联。
我相信，如果有人要实现自己的运行时，可能会被欺骗 - 因为MethodBase.GetCurrentMethod最终归结为此，在RuntimeMethodHandle中声明：
[SecurityCritical]
[MethodImpl(MethodImplOptions.InternalCall)]
private static extern IRuntimeMethodInfo
_GetCurrentMethod(ref StackCrawlMark stackMark);
在自定义运行时中，可以执行任何操作 - 并且将来它也可以执行任何操作。目前，我认为Microsoft运行时不会返回正确方法的唯一方法是代码内联;例如，不能代表Mono。然而，完全依赖于这种情况，就像依赖于内部类型的反射私有字段总是存在以使一段代码能够工作，我想。
在我尝试过的几乎所有情况下（我现在都不再担心）或有人试图证明需要能够可靠地识别调用方法，在分析之外，内联方法的问题总会出现。< / p>
但实际情况是，担心这些方法有多重要？
如果可靠性绝对至关重要，那么您将获得更多运气使用IL-rewriter后期编译来注入日志记录调用;这可能必然是方法感知的，因此可以破坏内联，即使它发生（如果重写的IL变得足够庞大，可能不会这样做，从而损害性能）。或者，如果您不想自己动手，可能会有一个AOP库 - 例如PostSharp。