Mono.Cecil 0.9 "cecil/light" 9
I started working on Mono.Cecil during the fall of 2004. In its current incarnation, it served me and a lot of people very well. But looking at it now, it aged quite a bit. The code still compiles on .net 1.1, is using old conventions, doesn’t have a real test suite, is quite memory hungry, and is not that optimized. Which doesn’t prevent it to be a useful and wide used library, but looking back; I could have done a lot of things differently.
And doing things differently is basically what I’ve been doing for the past two years in my free time. What originally started as a refactoring of Mono.Cecil for the decompiler, ended up as a rewrite from the ground up. And today I’m excited to make public what is the next version of Cecil, which I’ve been fondly calling “cecil/light”.
Let’s start with a warning; this version contains breaking changes with the previous API. I didn’t promise API stability for the previous code, but this iteration of Mono.Cecil, tagged 0.9, is a huge step towards 1.0 and API stability.
But let’s focus for a while on the bright and new side. Mono.Cecil 0.9 comes with:
- A cleaned and genericized API, I took this opportunity to clean some parts I hated in the old API.
- A smaller and easier to maintain C#3 code base (Mono.Cecil 0.9 compiled with optimizations by csc is about 250k against almost 400k for 0.6) which only requires a .net 2.0 compatible runtime.
- A test suite which is very easy to augment.
- Better support for pdb and mdb files and strong name assemblies.
- Complete support for PE32+ assemblies.
- Bug fixes that weren’t possible without large changes in the old code.
- Less memory consumption.
- Lazy loading of every metadata element.
- Speed and optimizations.
- Complete Silverlight support.
- A beginning of documentation on a wiki.
- A collection of extension methods to add features to Cecil when they’re not necessary to the core assembly.
I ported a few of my projects to this version of Cecil already, and it shows great results. I didn’t spend more than four hours per project to adjust the code in a branch. There’s a migration page on the wiki to help you. If it doesn’t answer your question, reach us on the mono-cecil group.
I took special care in testing this version, and waited to have something stable to make it public, but just like every rewrite, you might face bugs or regressions. I’m confident it won’t take long before it gets really stable. A few people had early access to this code base, and ensured it was at least working as well as the previous version, if not better most of the time.
I moved the development of this version of Mono.Cecil to github while I’ll be maintaining the previous code in the Mono tree, as it’s still used by a lot of tools there, that I haven’t migrated yet.
We’ll also be working on writing more documentation for 1.0, both as a serie of HOWTOs, and as a more traditional class library documentation. But everyone that has already used Cecil should be up to speed promptly.
Thanks to everyone that helped, whether they knew it or not. Many thanks to Rodrigo B. de Oliveira, Carlo Kok, Sébastien Pouliot, and all the contributors to Mono.Cecil. Thanks also to Jeroen Frijters for his fantastic work on his IKVM.Reflection.Emit assembly in which I sometimes took inspiration. Enjoy!
Picture by law_keven some rights reserved
Trackbacks
Use the following link to trackback from your own site:
http://www.evain.net/blog/articles/trackback/591

I’ve used Cecil on a couple of projects. Bookmarked this page for when I have time to check out the new version :)
Hey Innes, are you at liberty to share what those projects were? Maybe we could add them to the list of projects using Cecil?
Thanks Jean-Baptiste. This is a real great news… i guess i’m going to hack around with it tomorrow.
“yapluka”
Yes! Finally new version :) Cecil is like a drug, when you used it once, you just can’t resist to use it somewhere else!
Congratulation Jb!!
(sailro: gesundheit!)
I’ve used Cecil on a couple of internal projects, and one ‘external’ one. The internal projects were, a kind of static coverage analyser for generating reports on what methods our unit testing code calls, and a tool for generating a ‘stub’ C# project from input assemblies, to let us create XML documentation separate from our C++ codebase (C++/CLI XML doc support isnt very good).
The external project was not really a generally useful tool, but something we shipped to allow people to analyse their assemblies and generate a report on usage of our APIs. They could then upload the report to us if they wanted to, so we could get an idea of what APIs people were using.
I’ll check with the boss about putting it on the Cecil projects page.
I hope you will have enough time to make a great wiki and HowTo. Great work ‘mon cher Jb’
Great news everyone! Now it’s time to get that Cecil.Decompiler thingy up and running.