Когда MethodBase.GetCurrentMethod надежен / предсказуем? - PullRequest
Новая
       17

Когда MethodBase.GetCurrentMethod надежен / предсказуем?

2 голосов
/ 18 января 2012

Метод может быть встроенным; есть атрибут, предотвращающий это («есть атрибут для этого»). Тем не менее, очевидно, что метод может также не получить свой собственный кадр стека в x64 из-за оптимизации хвостового вызова JITter (http://www.hanselman.com/blog/ReleaseISNOTDebug64bitOptimizationsAndCMethodInliningInReleaseBuildCallStacks.aspx). Это повлияет на поведение MethodBase.GetCurrentMethod?

Обсуждения, которые я могу найти, в основном касаются встраивания ( Когда метод может быть встроен CLR? ). Хотя эти обсуждения интересны сами по себе, моя проблема в действительности заключается в том, при каких обстоятельствах - если таковые имеются - на что MethodBase.GetCurrentMethod можно положиться, чтобы определить тот же метод, в который программист поместил вызов (например, для поздней привязки к метод, для которого текущий метод действительно является суррогатом). Встраивание - это способ, которым можно обмануть MethodBase.GetCurrentMethod, но мне интересно, единственный ли это способ?

1 Ответ

2 голосов
/ 18 января 2012

Нет - метод либо встроен во время выполнения, либо нет.

Полагаю, что можно обмануть, если кто-то реализует свою собственную среду выполнения - поскольку MethodBase.GetCurrentMethod в конечном итоге сводится к этому, объявленному в RuntimeMethodHandle: 

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

В пользовательской среде выполнения это может делать все что угодно - и в будущем оно также может делать все что угодно. В настоящий момент я считаю, что единственный способ, которым среда выполнения Microsoft не вернет правильный метод, - это если код встроен; не могу говорить за моно, например. Однако полагаться на то, что это всегда так, все равно, что полагаться на всегда присутствующее отраженное приватное поле внутреннего типа для обеспечения работы части кода, я думаю.

Почти во всех случаях, когда я пытался (я больше не беспокоюсь об этом сейчас) или кто-то пытается оправдать необходимость иметь возможность надежно идентифицировать вызывающий метод вне профилирования, всегда возникает проблема встроенных методов.

Реальность, однако, насколько важно беспокоиться об этих методах?

Если надежность абсолютно необходима, вам больше повезет, если вы используете посткомпиляцию IL-rewriter для ввода вызовов в журнал; это может быть обязательно с учетом метода и, следовательно, может подорвать вставку, даже если это имеет место (чего не может быть, если переписанный IL становится достаточно громоздким, что снижает производительность). Или, если вы не хотите использовать свою собственную, библиотека AOP может быть в порядке - например, PostSharp .

...