Существует ли API для проверки MSIL динамической сборки во время выполнения?

Question

При использовании Reflection.Emit для сборки сборки во время выполнения я хотел бы проверить MSIL сборки перед сохранением на диск. Как PEVerify , но во время выполнения. Есть ли такой API?

Answer 1

Похоже, что peverify.exe является интерфейсом для c: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ peverify.dll (или c: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \peverify.dll для CLR 2.0), которая является нативной DLL (на самом деле peverify.exe также является нативной)

Я не вижу нигде этого документированного, так что, вероятно, это не публичный API,Возможно, вам удастся выяснить экспортированные функции из этой DLL, используя что-то вроде Dependency Walker , но я думаю, что было бы проще просто вызвать peverify.exe.

EDIT: неподтвержденная информация:

• На этапе компиляции Boo фактически вызывает peverify.exe .
• В своих тестах Nemerle вызывает peverify.exe .
• Castle.DynamicProxy вызывает peverify.exe в своих тестах.

Answer 2

Вместо использования PEVerify вы можете использовать декомпилятор ILSpy для внутрипроцессного решения, как описано здесь: http://www.codeproject.com/Tips/659692/Automated-MSIL-PE-verification-using-ILSpy

Краткое содержание статьи:

1. Соберите соответствующие библиотеки DLL для ссылки из вашего тестового проекта или средства проверки IL во время выполнения в этом случае
2. Выполните итерации по методам проверки с использованием Mono.Cecil
3. Для каждого метода добавьтеэто к AstBuilder, определенному в ICSharpCode.Decompiler, который выполняет проверку.Например,

var context = new DecompilerContext(method.Module) { CurrentType = method.DeclaringType };
var astBuilder = new AstBuilder(context);
astBuilder.AddMethod(method);

По производительности я не проверял, какой метод быстрее.Хотя этот метод работает в процессе, он может быть медленнее, поскольку абстрактное синтаксическое дерево создается при проверке IL (для проверки этой теории потребуется настроить тест производительности).

Я нашел декомпилятор ILSpyчтобы быть более надежным, чем PEVerify, как указано в вышеприведенной статье, в одном случае PEVerify объявил одну сборку допустимой, в то время как ILSpy правильно дал красивую трассировку стека, указывающую на мою ошибку при генерации.

Answer 3

Вызов peverify, вероятно, действительно лучший подход, но peverify находится во многих разных каталогах, в зависимости от работающей версии .NET.Вы можете попытаться перечислить все эти пути и проверить последний, но это было как минимум 6 различных путей на последнем счете IIRC, и оно не является кроссплатформенным, т.е.не включает Mono.

Недавно я обнаружил, что могу просто связать сборку Microsoft.Build.Tasks, а затем создать экземпляр Microsoft.Build.Tasks.GetFrameworkSdkPath и вызвать свойство Path..Одно странное поведение, которое я заметил, заключается в том, что при обращении к пути в первый раз возникает исключение, но если вы просто проглотите это исключение, с этого момента вы сможете получить доступ к пути.() .Path, "bin \ peverify").

Answer 4

Отладка LCG позволяет вам отлаживать сгенерированный код во время выполнения, используя Windbg.

Возможно, это может вам помочь.