Mono.Cecil is an open source framework, part of the Mono project, that reads .NET assemblies, but also that writes .NET assemblies. It is developed by Jean Baptiste Evain that now works full-time on the Mono project.


System.Reflection is a great framework because it is the .NET core base of several good practices that revolve around the Dynamic / Plug-In / Dependency Injection / Late-Binding kind of patterns . These patterns currently represent a successful trend in the .NET community and you can convince yourself by having a glance at the List of .NET Dependency Injection Containers framework recently done by Scott Hanselman.


The object of the current post is to explain that System.Reflection must not be used to do something else than Late-Binding like code. Especially, System.Reflection should not be used to do any kind of code analysis. We (the NDepend team) learnt this lesson the hard way after more than 3 years of hard-core work with System.Reflection. Hopefully we refactored our code that does static analysis and it is now (since NDepend v2.7) entirely based on Mono.Cecil. We are now plainly satisfied with this integration (btw, there is no licensing issue in using any code from Mono in a commercial or proprietary application).


So what's wrong with System.Reflection? It actually comes from its primary intention of doing Late-Binding things. As a result it can't consider code as just raw data. And this leads to many limitations such as:

• You cannot unload an assembly once it is loaded into an AppDomain by System.Reflection. In its excellent book Customizing the Microsoft .NET Framework Common Language Runtime, Steven Pratschner explains that this limitation might be overcome in the future but it is still very unsure.

• At any time, browsing the code of an assembly loaded with Reflection might trigger a Code Access Security (CAS) exception because the data you’re playing with are still considered as code.

• It has poor performance (I suspect that CAS security checks plays a major role in this perf issue).

• It consumes a lot of memory (here also I suspect that it is because the CLR considers data as code) and it is hard to release this memory once you went through all the code of an assembly

• You cannot load 2 different versions of an assembly inside an AppDomain (at least not intentionally as I explained here).

• As a result of the previous limitation you cannot load a Microsoft assembly that has a different version than the current CLR version (for example, you cannot analyze mscorlib v1.1 from System.Reflection in mscorlib v2.0).

You can also read this great article from Joel Pobar Dodge Common Performance Pitfalls to Craft Speedy Applications if you want more understanding on how Reflection relies internally on cache that makes memory grow and some benchmark in the average performance of Reflection in general. Since .NET v2, System.Reflection supports a kind of read-only mode but as a heavy user of this feature I came to the conclusion that most of problems persist with this mode.

Another problem is that System.Reflection suffers from severe limitations (bugs?!) if you try to analyze out of the beaten path assemblies, I mean, not classic AnyCPU C# or VB.NET assemblies. For example:
      

• It tosses many unexpected exceptions when it comes to tricky scenario where the assemblies analyzed contain static cctor or complex custom attributes.

• When you use the class System.Runtime.InteropServices.Marshal to get information on analyzed code elements, you can get unexpected exceptions.

• It doesn't cop well with complex C++/CLI assemblies (that often don't respect the CLI) and this often leads to unexpected exceptions.

• It doesn't cop well with not AnyCPU assemblies (i.e compile option 32/64bits) and here also, this often leads to unexpected exceptions.
  

Finally System.Reflection suffers from some others by-design limitations because:

• It doesn't parse IL.

• It doesn’t do the distinction about TypeRef and TypeDef as Jm Stall explains here. It means that you will get some UnresolvedException when you try to get information about a code element that is referencing some code elements in some assemblies not currently loaded in the current AppDomain.

• It doesn't know about TypeSpec as Jm Stall explains here. It means that there will always be some tricky case such as a {ref List<U>*} typed parameter where Reflection won't do distinction between 2 overloads of a methods.
  

This post sounds as a bashing of System.Reflection but it is not. This framework is central to implement late-binding scenarios and personally I had a lot of fun with it. Also, IMHO Microsoft engineers did an awesome job at making sure that method calls and object instantiations thought reflection comes with really high performance (as Ayende mentioned recently). See also this great article from Joe Duffy on CLR method call internals. And finally, Reflection (and especially Reflection.Emit) is central to the new dynamic language trend (DLR). Here what Jim Hugunin, creator of IronPython wrote on its blog: We began to take advantage of the great new features for dynamic languages already shipping in .NET 2.0 such as DynamicMethods, blindingly fast delegates and a new generics system that was seamlessly integrated with the existing reflection infrastructure.

But when it comes to code analysis, Mono.Cecil is definitely the best option I came across. The object model is pure and made me learn the CLI much better than any other sources. The performances are awesome and the support provided by Jb Evain is just perfect. These last months’s we reported several bugs and most of time the fix came within a few hours! As a result, we really have a high trust in Mono.Cecil and my personal feeling it shouldn't be far from bug-free. Also, I didn’t talk at all about the great ability of Cecil to tweak assembly IL (simple because I didn't need it yet) but you can have a look here to see this amazing feature in action.