#SIGIL GENERATOR APP CODE#

Most opcodes in ILGenerator are emitted with a call to one of Emit's overloads, the problem is that Emit(.) does no checking that the instruction is actual sensible.įor example 1: var dyn = new DynamicMethod('foo', typeof(void), new Type) ħ: var del = (Action)dyn.CreateDelegate(typeof(Action)) ĭoesn't fail to compile, even though line #4 is nonsensical (the Add opcode takes no immediate values). KM: When using ILGenerator, there are two big stumbling blocks. InfoQ: What are the challenges of emitting IL at runtime? * Generic types, in the absence of constraints, could be either structs or reference types which has to be reflected in the emitted IL and handled in validation. Unbound generic types complicate validation and generation*, and since in the typical case all types are known when using Sigil there's been little demand for to support them. Fault blocks aren't really a thing in C#, and aren't legal in DynamicMethod anyway.

#SIGIL GENERATOR APP CODE#

There are a few use cases Sigil doesn't support (which are possible with ILGenerator): fault blocks and emitting code that uses generic (ie.

for which reflection is often used can benefit from Sigil/ILGenerator. Kevin Montrose: Typically IL is generated as a faster alternative to reflection, so tasks like (de)serialization, type mapping, mocking, etc. InfoQ: What are the most suited scenarios for generating IL? Is it possible to replace any piece of code using reflection with ILGenerator/Sigil? InfoQ reached out with Sigil's creator Kevin Montrose, team lead at StackOverflow, to get a better understanding of ILGenerator and Sigil. It wraps ILGenerator in a finer-grained interface, automates some optimizations and provides validations for the generated IL. Sigil is a library for generating Common Intermediate Language (CIL).

Sigil generator app