Метод встраивания по собственным изображениям сборок

Как объясняется в еще один вопрос, Ngen обычно разрешается только встроенным методам в сборках, если метод имеет TargetedPatchingOptOutAttribute.

Но это также верно для жестких сборок с помощью DependencyAttribute с LoadHint.Always?

edit: Возможно, ответ на мой первоначальный вопрос - нет, иначе нет смысла, что TargetedPatchingOptOutAttribute используется в mscorlib, поскольку эта сборка всегда жестко связана (у нее есть DefaultDependencyAttribute set). Поэтому я хотел бы перефразировать мой вопрос: Является ли TargetedPatchingOptOutAttribute единственным способом получить метод, встроенный в собственные изображения сборок?

Ответ 1

Кажется, что другой вопрос привел меня к совершенно неправильному предположению. Методы в наших собственных сборках заключены в в пределах встроенных ограничений изображения, даже если они не являются жесткой границей и не установлены TargetedPatchingOptOutAttribute. Этот атрибут влияет только на сборки .NET Framework.

Сообщение в блоге Microsoft содержит неплохую информацию о TargetedPatchingOptOutAttribute:

"Целевой патч - метод не хватает TargetedPatchingOptOutAttribute" - это относится к новой функции в CLR 4, где изображения NGEN - это больше версия эластичный. В двух словах мы надеемся, что сможем применить патч или исправить в mscorlib.dll и не перекомпилировать все другие родные изображения на машине, которые зависят от нее. Это должно применяться только к методов в библиотеках классов .NET Framework, поскольку они являются только узлы, которые могут выбрать эту функцию.

Это означает: поскольку сборки .NET Framework теперь поддерживают целевое исправление в .NET 4.0, методы из этих сборок обычно не могут быть встроены, Но методы, отмеченные знаком TargetedPatchingOptOutAttribute, критичны по производительности и поэтому исключают целевое исправление (что означает, что когда они когда-либо меняются, все собственные образы, которые используют этот метод, необходимо перекомпилировать). Поскольку наша собственная сборка не использует целевые исправления, нет никаких оснований предупреждать использование метода для встроенных образов.

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

Версия TL;DR: не заботятся о TargetedPatchingOptOutAttribute, ее следует использовать только в сборках .NET Framework. Метод встраивания саморазвитых сборок работает одинаково с Ngen и JIT.