Jb in a nutshell

newton:~/Sources/temp jbevain$ monodis dummy.dll 
.assembly 'dummy'
{
  .hash algorithm 0x00000000
  .ver  0:0:0:0
}

.module Dummy // GUID = {1764306C-0167-41BE-86B8-52ED3980F771}

Pretty simple assembly huh? Well, I’ve never been as happy to see the output of monodis. After three days of hard work, it is what Cecil produced while running this code:

<span class="kwrd">using</span> System;

<span class="kwrd">using</span> Mono.Cecil;

<span class="kwrd">public</span> <span class="kwrd">class</span> EntryPoint {

    <span class="kwrd">public</span> <span class="kwrd">static</span> <span class="kwrd">void</span> Main ()
    {
        Console.WriteLine (<span class="str">"Running ..."</span>);
        WriteDummyAssembly ();
        Console.WriteLine (<span class="str">"... Ended"</span>);
    }

    <span class="kwrd">public</span> <span class="kwrd">static</span> <span class="kwrd">void</span> WriteDummyAssembly ()
    {
        IAssemblyDefinition asm = AssemblyFactory.DefineAssembly (
            <span class="str">"dummy"</span>, <span class="str">"Dummy"</span>, TargetRuntime.NET_1_1);
        AssemblyFactory.SaveAssembly (asm, <span class="str">"dummy.dll"</span>, AssemblyKind.Dll);
    }
}

This does not looks very complicated but believe me, writing PE binary are neither simple nor fun. The good news is that both Mono and Cecil are able to read this assembly. I mean, Cecil can read assemblies it has produced, wow, isn’t there some kind of beauty here ? The bad news is that Microsoft’s Framework still throws me an error, but heh!

Ok ok, stop blogging, go back to work.

El Miguel blogged about the third revision of the ECMA CLI 335 standard.

As the author of a library that should be able to emit assemblies compliant to the above standard, I’ve been happy to see in this document the description of a standardized debugging symbols store, just like Microsoft’s PDB, and Mono’s MDB. Having, and using, such a standard, would allow users to share debugging infos between differents CLI informations. For instance you’re developping an ASP.NET site on Windows in Visual Studio, you compile the whole thing in Debug mode, and then, you deploy your libraries on a Linux server, hosting XSP. If an error occurs in your code, you would be able to see exactly where. Otherwise, the detail level for an error in a Release configuration is the method. Not very easy to find where errors are in this way.

So the idea of having a file format standardized is somewhat exciting. Especially for me, since I won’t have to write a factory of debugging store emitters…

After some discussions and investigations, it appears that the CLIDB format is the kind of symbols store that the SSCLI (aka Rotor) emits. Also I’ve been said that Microsoft does not plans to implement this standard, because they’re happy with their PDB files. Also, if Microsoft’s CLR does not understands this format, and .net compilers are not able to emit this kind of store, why would Mono implement this standard, as they already have a file format?

Let me recap:

• This day, we can’t share debugging infos between CLI implementations.
• Mono emits its own, but Open Source MDB format.
• Microsoft’s CLR emits Microsoft’s PDB files.
• Microsoft is not willing to open the PDB file format, they consider it as an internal feature.
• Microsoft has open the format used by its Open Source implementation of the CLI (the SSCLI): the CLIDB file format.
• The CLIDB file format is now part of the ECMA-335 CLI standard.
• But why would other implementors use this file format instead of their own if the main one does not the same?

If you’re just like me willing to be able to use one and only one file format to store debugging symbols, please let Microsoft know it.

Cecil’s timeline

• Lazy and Aggressive loading of assemblies
• Both Reflection and Metadata level available
• .net 1.1 profile support
• Assembly round-triping
• modreq/modopt, pinned types, resource embedding, ...
• bugs

• .net 2.0 profile support
• Emit mdb debugging symbols (maybe pdb too)
• bugs correction I guess
• another few bugs

I’ve found something interesting. In SRE, you are able to emit assemblies in memory, then use them directly. I was afraid that with Cecil I had to write the assemblies on the disk before loading them, but it seems that I won’t have to, since there is a Assembly::Load(byte[]) method that should be usable. But i don’t think that it will be a very used feature, because in SRE2, you have almost everything you want to emit at runtime what you need.

Paris

The good thing when someone come to visit you, it’s that you go to places your not used to, even in the city you’re living in. So i’ve spend the last few days visiting Paris, and I have to admit that I love this city (expected the subway). Some pics taken in the “Museum d’histoire naturelle”.

The gallery
A whale

A long time I have not blogged. Mainly spent my time working on Cecil. Better than a long talk, here is an example of what Cecil is able to do now. There is a name for programs that write themselves, I’ve forget it, and my example is not really one of them. My example is a very simple C# console program, but it will print its CIL representation, almost like ildasm.

I’ve not included the source and the result on the blog, because they are not really short. The source is viewable here : C# source. We simply load an assembly using Cecil, then we print the content of the methods. Easy no ? Let’s take a look at the output : here.

I have still a lot of work to do, and the API is not really stable, but I’m close to what I want. Once I’ll get it, I think I’ll call for contribution on this blog, to achieve the writing part of Cecil. Stay tuned !