Is there an API for verifying the MSIL of a dynami

Question

When using Reflection.Emit to build an assembly at runtime, I'd like to verify the assembly MSIL before saving to disc. Like PEVerify but at runtime. Is there such an API?

Answer 1

Instead of using PEVerify you could use the ILSpy's decompiler for an in-process solution, as described here: http://www.codeproject.com/Tips/659692/Automated-MSIL-PE-verification-using-ILSpy

A summary of the article is:

1. Collect the relevant DLLs to reference from your test project, or runtime IL checker in this case
2. Iterate through the methods to verify using Mono.Cecil
3. For each method, add it to the AstBuilder defined in ICSharpCode.Decompiler which performs the validation. Eg.

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

Performance-wise I have not checked which method is faster. Although this method is in-proc it may be slower since the Abstract Syntax Tree is built as the IL is validated (I'll have to setup a performance test to check this theory).

I found the ILSpy decompiler to be more reliable than PEVerify as pointed out in the above article, in one instance PEVerify declared one assembly to be valid, while ILSpy correctly gave a beautiful stack trace indicating my error in generation.

Answer 2

Debugging LCG allows you to debug the generated code at runtime using Windbg.

Maybe it can help you.

Answer 3

It seems that peverify.exe is a front-end to c:\Windows\Microsoft.NET\Framework\v4.0.30319\peverify.dll (or c:\Windows\Microsoft.NET\Framework\v2.0.50727\peverify.dll for CLR 2.0), which is a native DLL (actually, peverify.exe is also native)

I don't see this documented anywhere so it's probably not a public API. You may be able to figure out the exported functions from that DLL using something like Dependency Walker, but I think it would be simpler to just call peverify.exe.

EDIT: anecdotal evidence:

• In a compiler step, Boo actually calls peverify.exe.
• Nemerle calls peverify.exe in its tests.
• Castle.DynamicProxy calls peverify.exe in its tests.

Answer 4

Calling peverify is indeed probably the best approach, but peverify is located in many different directories depending on the running version of .NET. You can try to enumerate all these paths and check for the latest one, but this was at least 6 different paths at last count IIRC, and isn't cross-platform, ie. doesn't include Mono.

I recently found that I could just link to the Microsoft.Build.Tasks assembly, and then create an instance of Microsoft.Build.Tasks.GetFrameworkSdkPath and call the Path property. One weird behaviour I noticed is that accessing the path the first time throws an exception, but if you just swallow that exception you can access the path from then on.

Peverify.exe is then Path.Combine(new GetFrameworkSdkPath().Path, "bin\peverify").