Is there an API for verifying the MSIL of a dynamic assembly at runtime?

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?

Lebron

You don't want to just execute PEVerify after saving it to disk, I assume? – Cyruscyst

@jeffamaphone - i'd rather avoid it, but that's my backup plan! – Lebron

Answer 1

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.

Flintlock

Neat, thanks for the tips Mauricio - I'll check this out when I get the chance and let you know how it works out. – Lebron

Thanks Mauricio - I still haven't had the chance to look into accessing peverify.dll directly at runtime, but based on your anecdotal evidence, I think I'll follow the save assembly to disc -> run peverify.exe approach even if it is a bit clunky. That should be sufficient to start, and I'll revisit using pverify.dll at runtime if the need in practice emerges. – Lebron

Answer 2

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.

Prudy

Thanks for the info, @ilen, I'll definitely have to look into this! – Lebron

@StephenSwensen, Wow, you are willing to refactor the code after 2 years ;) .. I read your question again and noticed that ideally you would like to avoid saving to disk. For this you would need to either port Reflection.Emit to Mono-Cecil emit or write some translator – Prudy

Haha, yes indeed. This is for a continuing hobby project that I have worked on as recently as last night (code.google.com/p/nl-compiler), so it is all about learning and applying the best techniques I can find. – Lebron

I forget the details, but I believe I chose to use Reflection.Emit over Mono-Cecil due to limitations it had with running dynamic assemblies in process (it was not sufficient for building an interactive compiler). – Lebron

Answer 3

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

Maybe it can help you.

Attainture

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").

Cita