Jb in a nutshell

Certains vont à la Tour Eiffel, d’autres se ruent dans des Starbucks, mais moi, quand je monte conquérir Paris, je vais aux réunions alt.net. C’est souvent amusant, et toujours de bonne compagnie. En plus j’ai l’honneur, que dis-je le privilège d’être en haut de l’affiche de la prochaine réunion. Évidemment, je n’aurai pas de complet bleu, moi j’aime les rayures.

Lundi prochain, 12 octobre, je vais présenter MonoTouch. MonoTouch, c’est un produit de Novell, qui permet d’écrire des applications pour iPhone en C#, comme on le ferait pour le framework .net. Ou presque.

Cette session sera donc l’occasion de voir ce que l’on peut faire avec, de rentrer un peu dans les détails du pourquoi du comment ça marche, et d’en discuter. Parce que c’est vraiment ce qui fait le charme de ces rencontres alt.net. Les discussions post-session, un verre à la main, une cravate dans l’autre.

Notre hôte pour cette session sera Zenika, qui m’a réservé une page rien que pour moi, et surtout qui permet de s’inscrire. Dépêchez vous de vous inscrire, le nombre de place est probablement limité.

Le synopsis de la session:

Aujourd’hui, dans l’informatique, tout le monde ou presque a entendu parler de l’iPhone. Et à plus forte raison depuis que celui-ci supporte le copier-coller. C’est aujourd’hui un acteur important dans le monde de la mobilité, et sa démocratisation rapide en fait une plateforme de choix pour développer des applications, aussi bien pour l’entreprise que pour le particulier.

Si à l’origine développer pour cette platforme signifiait utiliser le langage d’Apple, l’Objective-C, on assiste à la naissance de solutions tierces destinées à fournir d’autres moyens de programmer pour l’iPhone.

Cette session sera l’occasion de voir non seulement comment il est possible de réutiliser son code et ses compétences .net sur l’iPhone grâce à MonoTouch, mais aussi d’en expliquer le fonctionnement.

À lundi prochain donc.

There has been a lot of interest towards the Rx framework lately. It’s definitely an interesting piece of software, and the video linked on channel 9 is quite fascinating. The only issue is that the only assembly you can get right now is compiled against Silverlight, making it impossible to use on the traditional .net framework. Impossible, really?

Well, I for one would not recommend it, but if you really can’t wait to try it, you could use this little piece of code which uses Cecil to turn the assembly compiled against Silverlight into an assembly that will work on the .net framework. Of course the assembly will lose its strong name in the process. But at least, it will be usable.

For instance, here’s the sample that Jafar is showing on his blog, running on Mono:

Update: don’t miss the comment Sébastien posted, and how he would do it with Reflexil.

Update: the code has been moved to its own project page.

Let’s consider you’re writing a LINQ provider. And that you need to opimize the following LINQ query:

from Person p in db where p.Age > 18 select p;

Let’s add a constraint. The underlying storage engine stores data according to the field name. That would mean that when generating the query for the underlying storage system, you’ll have to map

p.Age

into something that the underlying storage system will understand. In that case, a field. And all you have is a MemberExpression, giving you a PropertyInfo.

The issue here is that you have no way to get the FieldInfo backing the property. If you think about it, it’s normal. The setter and the getter of a property being traditional methods, they can contain any kind of code. Meaning that you can’t always find a field backing the property.

But in that case, it’s ok, we’re only interested in those forms of properties:

public int Age { get; set; }

private string name;

public string Name {
    get { return name; }
    set { name = value; }
}

Of course here what’s interesting is how to actually get the field. I’ve used the Reflection based CIL reader I wrote about yesterday. I disassemble the body of either a getter or a setter of the property, and if it matches a simple IL pattern, that is, if it looks to be a property backed by a field, I simply return the field.

To do the actual IL matching, I re-implemented something Rodrigo and I wrote when we were working on instrumenting assemblies at db4o. The code itself is pretty neat.

Anyway, that’s another opportunity to write a simple extension method:

public static FieldInfo GetBackingField (this PropertyInfo self)

Again, you’re more than welcome to have a look at the implementation. Don’t forget that it depends on the Reflection based CIL reader.

Update: the code has been moved to its own project page.

As I was writing, earlier this month, when I worked on a static aspect weaver, the first library we used, to programmatically retrieve the CIL bytecode, was a library published by Lutz Roeder (the original author of the most famous Reflector tool), called ILReader.

It suffered from a number of limitation, and you were tied to the whole System.Reflection infrastructure. Which, during the .net 1.0 time, was somewhat limited, and lacked a few features required to get access to every single detail in an assembly, including the CIL bytecode. It evolved since, for instance, starting from .net 2.0, there’s a GetILAsByteArray on a MethodBody used to get the raw CIL code.

Anyway, most of those concerns were addressed by Cecil, but still, for some use-cases, it could be nice to be able to have access to the CIL bytecode at a higher level of abstraction than a plain raw byte array.

On .net, you can use a library also named ILReader, but it has a few checks that are specific to .net, there’s no information about a license of the code, and also, I’m not especially fond of the way instructions are represented.

So last time, for an hack I’ll soon write about, I extracted Mono.Cecil’s Instruction type, and wrote a cute extension method, or rock, as I like to call them. Its signature:

public IList<Instruction> GetInstructions (this MethodBase self)

I would have loved to declare the extension method on the System.Reflection.MethodBody type, to make things more consistent with the methods it already has, but there’s no cross platform way to get a System.Reflection.MethodBase from a System.Reflection.MethodBody.

Anyway, it’s terribly easy to use if you’ve already used Cecil. The only difference is that for branches, the operand is the offset as an integer, not the target instruction. As a sample usage, here’s a (very) incomplete CIL reflection based disassembler:

static void PrintByteCode (MethodInfo method)
{
    foreach (Instruction instruction in method.GetInstructions ())
        PrintInstruction (instruction);
}

static void PrintInstruction (Instruction instruction)
{
    Console.Write ("{0}: {1} ",
        Labelize (instruction.Offset),
        instruction.OpCode.Name);

    switch (instruction.OpCode.OperandType) {
    case OperandType.InlineNone :
        break;
    case OperandType.InlineSwitch :
        var branches = instruction.Operand as int [];
        for (int i = 0; i < branches.Length; i++) {
            if (i > 0)
                Console.Write (", ");
            Console.Write (Labelize (branches [i]));
        }
        break;
    case OperandType.ShortInlineBrTarget :
    case OperandType.InlineBrTarget :
        Console.Write (Labelize ((int) instruction.Operand));
        break;
    case OperandType.InlineString :
        Console.Write ("\"{0}\"", instruction.Operand);
        break;
    default :
        Console.WriteLine (instruction.Operand);
        break;
    }

    Console.WriteLine ();
}

And of course, you’re welcome to have a look at the implementation, under the MIT/X11 license.