cil

When delegate keyword is used in C#, the C# compiler automatically generates a class derived from System.MulticastDelegate class. This compiler generated class contains 3 methods as well: Invoke, BeginInvoke and EndInvoke . All these three methods are marked public virtual extern but interestingly the class itself is marked sealed . Virtual methods defined in a sealed class not only strikes as counter-intuitive but are actually illegal in C#. So my question is, is there a specific reason for this or is it just one of those harmless things done keeping in mind some hypothetical future

Many methods in the BCL are marked with the [MethodImpl(MethodImplOptions.InternalCall)] attribute. This indicates that the "method is implemented within the common language runtime itself". What was the point of designing the framework in this way over having specified explicit CIL instructions that the runtime would be forced to implement? Ultimately, the attribute is creating contractual obligations for the runtime, but in a way that appears to me to be confusing and not immediately obvious. For example, Math.Pow could have been written this way (excuse my informal mixture of C# + IL and

What happens exactly when I launch a .NET exe? I know that C# is compiled to IL code and I think the generated exe file just a launcher that starts the runtime and passes the IL code to it. But how? And how complex process is it? IL code is embedded in the exe. I think it can be executed from the memory without writing it to the disk while ordinary exe's are not (ok, yes but it is very complicated). My final aim is extracting the IL code and write my own encrypted launcher to prevent scriptkiddies to open my code in Reflector and just steal all my classes easily. Well I can't prevent reverse

All code written in .NET languages compiles to MSIL, but are there specific tasks / operations that you can do only using MSIL directly? Let us also have things done easier in MSIL than C#, VB.NET, F#, j# or any other .NET language. So far we have this: Tail recursion Generic Co/Contravariance Overloads which differ only in return types Override access modifiers Have a class which cannot inherit from System.Object Filtered exceptions (can be done in vb.net) Calling a virtual method of the current static class type. Get a handle on the boxed version of a value type. Do a try/fault. Usage of

In many MSIL listings, I have observed the following: System.Nullable`1<!0> etc ... or class !0 etc ... What's the meaning of !0 in these circumstances? This is quirk of the decompiler you use to look at a .NET assembly. It is the behavior of ildasm.exe, other ones like Reflector or ILSpy get this right. The Microsoft programmer who wrote it took a shortcut, he generates a string from the IL that just displays the type argument the way it is encoded, without writing the extra code to lookup the type argument name in the metadata. You need to read !n as the n-th type argument of the generic

In a comment on this answer (which suggests using bit-shift operators over integer multiplication / division, for performance), I queried whether this would actually be faster. In the back of my mind is an idea that at some level, something will be clever enough to work out that >> 1 and / 2 are the same operation. However, I'm now wondering if this is in fact true, and if it is, at what level it occurs. A test program produces the following comparative CIL (with optimize on) for two methods that respectively divide and shift their argument: IL_0000: ldarg.0 IL_0001: ldc.i4.2 IL_0002: div IL

What are some resources for making a CLR/.NET language debuggable? I'm developing an ActionScript 3 to IL compiler, which uses DLR CallSites and CallSiteBinders to handle the dynamic aspects of the otherwise static programming language. I'm looking for any information on making the emitted IL map back to the source code, and I'd also like to know how I can make the dynamic call sites map back as well. So this is ultimately two questions: How can I make the IL debuggable? How can I make the DLR call sites debuggable? Any help would be greatly appreciated! What I'm looking for in terms of

Is there a way to modify existing .NET assemblies without resorting to 3rd party tools? I know that PostSharp makes this possible but I find it incredibly wasteful that the developler of PostSharp basically had to rewrite the functionality of the whole System.Reflection namespace in order to make existing assemblies modifiable. System.Reflection.Emit only allows the creation of new, dynamic assemblies. However, all the builder classes used here inherit from the basic reflection classes (e.g. TypeBuilder inherits from System.Type ). Unfortunately, there doesn't seem to be a way to coerce an

Using ildasm and a C# program e.g. static void Main(string[] args) { } gives: .method private hidebysig static void Main(string[] args) cil managed { .entrypoint // Code size 2 (0x2) .maxstack 8 IL_0000: nop IL_0001: ret } // end of method Program::Main What does the hidebysig construct do? Jon Skeet From ECMA 335 , section 8.10.4 of partition 1: The CTS provides independent control over both the names that are visible from a base type (hiding) and the sharing of layout slots in the derived class (overriding). Hiding is controlled by marking a member in the derived class as either hide by name

I'm going through MSIL and noticing there are a lot of nop instructions. The MSDN article says they take no action and are used to fill space if the opcode is patched. They're used a lot more in debug builds than release builds. I know that these kinds of statements are used in assembly languages to make sure an opcode fits on a word boundary, but why is it needed in MSIL? NOPs serve several purposes: They allow the debugger to place a breakpoint on a line even if it is combined with others in the generated code. It allows the loader to patch a jump with a different-sized target offset. It