Codingly

Vous allez probablement m’en vouloir à force, mais j’ai décidé de continuer mes expériences autour d’INotifyPropertyChanged. Cette fois-ci, en utilisant Mono.Cecil pour faire un peu d’IL rewriting. Où comment tisser un aspect sans utiliser de framework AOP. Comparée à celle basée sur PostSharp.Laos, cette solution a un inconvénient majeur : elle est plus roots.

En revanche, aucune autre méthode à ma connaissance ne permet d’obtenir un tissage aussi fin. Par fin, j’entends spécifique, propre, non pollué par le code que génèrent les outils d’AOP classiques pour supporter les mécanismes d’interception. Donc les performances seront à la clé puisqu’une fois l’assembly retravaillé avec Cecil, il ne sera plus possible de faire la différence entre son code IL et celui qui aurait été généré si nous avions implémenté INotifyPropertyChanged à la main. Le développement aura juste été un peu plus cher…

Même si la plupart du temps vous préfèrerez sans doute bénéficier de l’abstraction offerte par les outils d’AOP classiques, vous trouverez peut-être excitant de jouer avec Cecil pour déveloper des aspects bas niveau en mettant les mains dans le camboui. (Vous pouvez aussi trouver ça naze au point d’en bailler, hein.)

Bref, ce post va plus ressembler à un article sur Cecil qu’à un article sur INotifyPropertyChanged. Il y aura probablement deux parties, mais ce n’est pas une promesse :

• Part 1 : première version d’un transformer utilisant Cecil pour implémenter INotifyPropertyChanged (cet article)
• Part 2 : version améliorée du transformer lançant l’évènement de notification uniquement lorsque la valeur affectée à la propriété est différente

Eventuellement, je fournirai quelques pistes pour lancer automatiquement ce genre de transformations en post-build dans la seconde partie, si seconde partie il y a.

Mais commençons par le commencement, en prenant pour victime la Person des articles précédents. Le but est de pouvoir écrire :

	[NotifyPropertyChanged]
	public class Person
	{
		private string name;

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

et d’obtenir au final une classe Person implémentant INotifyPropertyChanged et capable donc de notifier par l’événement PropertyChanged les changements de ses propriétés.

Cecil permet de charger un assembly, de l’inspecter et de le modifier éventuellement avant de le sauvegarder, de le copier, etc. L’idée consiste donc à :

1. Compiler le code ci-dessus normalement, afin d’obtenir un assembly
2. Lancer un transformer, qui utilise Cecil afin de charger cet assembly
3. Modifier l’assembly, toujours avec Cecil, pour y injecter l’implémentation d’INotifyPropertyChanged en manipulant le code CIL.
4. Sauvegarder l’assembly modifié

Le transformer

Dans cette première version, imaginons quelque chose de naïf : un programme en ligne de commande, qui prend en argument le chemin de l’assembly à instrumenter :

    private static void Main(string[] args)
    {
        if (args.Length == 0)
        {
            Console.WriteLine("Usage: transformer <assembly file>");
            return;
        }
        new Transformer(path).Run();
    }

D’ailleurs, je vais continuer à être naïf en laissant de côté la gestion du logging, des exceptions, etc. Les snippets présentés ici n’en seront que plus lisibles, à défaut d’être solides.

Commençons par une vue d’ensemble des étapes nécessaires à la transformation des assemblies, que nous détaillerons ensuite. (Vous aimez les opcodes ?)

1. Chargement de l’assembly à instrumenter
2. Identification des types à modifier : on recherche ceux qui sont taggés par notre attribut [NotifyPropertyChanged]
3. Transformation de chacun de ces types pour leur faire supporter INotifyPropertyChanged
4. Sauvegarde de l’assembly modifié

Le schéma ci-dessous met en avant les différentes étapes de la transformation :

• [#1] Implémentation proprement dite de l’interface INotifyPropertyChanged
• [#2] Ajout d’une fonction « helper » pour le déclenchement de l’évènement PropertyChanged
• [#3] Instrumentation des setters, en utilisant la méthode précédente pour lancer les notifications

Voyons comment implémenter ça. Rappelez-vous, tout commence par :

	new Transformer(path).Run();

Le constructeur (qui en fait sans doute un peu trop) :

public Transformer(string assemblyPath)
{
    this.assemblyPath = assemblyPath;
    this.assembly = AssemblyFactory.GetAssembly(assemblyPath);
    this.assembly.MainModule.LoadSymbols();
    this.assembly.MainModule.FullLoad();
}

Assez trivial : on laisse tout le travail à Cecil. Son AssemblyFactory nous permet de récupérer la définition de l’assembly à modifier. Afin de conserver les sequence points et permettre de debuguer l’assembly modifiée, on charge les infos de debug. L’appel à la méthode FullLoad permet de charger en mémoire toute la représentation du module principal, afin de pouvoir la modifier par la suite.

Petite parenthèse introductive : Plusieurs fois, dans les méthodes que je vais présenter par la suite, on aura besoin de récupérer une TypeReference, à partir d’un Type. Lorsque ce sera le cas, on utilisera une des deux méthodes suivantes :

private TypeReference GetReference(Type type)
{
    TypeReference typeReference = this.assembly.MainModule.TypeReferences[type.FullName]
                                  ?? this.assembly.MainModule.Import(type);
    return typeReference;
}

private TypeReference GetReference<T>()
{
    return GetReference(typeof (T));
}

Leur fonctionnement est simple : si on a déjà chargé le type dans le module principal de l’assembly en cours de modification, on retourne directement la TypeReference correspondante, sinon on importe le type pour créer la référence. Car Cecil fait bien la distinction (qui existe au niveau CIL) entre les définitions et les références pour les différents éléments du code (types, fields, methods, etc.)

Lorsqu’on veut modifier une méthode, par exemple, on va travailler sur sa définition. Mais si on désire simplement l’appeler, il nous faut juste sa référence. Ce modèle, plus juste que celui proposé par l’API de réflexion de la BCL peut sembler troublant au premier abord, mais s’avère au final plus puissant puisqu’il colle directement avec les spécifications du langage intermédiaire. Fin de la parenthèse.

Bien, on a de quoi commencer l’autopsie du Transformer, dont le nom est plus que douteux… La méthode Run semble être un point de départ judicieux pour notre analyse :

public void Run()
{
    foreach (TypeDefinition type in GetTypesToWeave())
    {
        MethodReference firePropertyChangedMethod = WeaveINotifyPropertyChanged(type);
        WeaveEventTriggers(type, firePropertyChangedMethod);
    }
    this.assembly.MainModule.SaveSymbols();
    AssemblyFactory.SaveAssembly(this.assembly, this.assemblyPath);
}

La méthode GetTypesToWeave permet de retourner tous les types à modifier, c’est à dire ceux qui sont décorés par notre attribut [NotifyPropertyChanged]. Ce dernier devra donc être défini dans un assembly quelconque, référencé à la fois par le code client – celui qui contient les types à instrumenter – et par notre transformer. Chacun des types est ensuite transformé par les appels successifs aux méthodes WeaveINotifyPropertyChanged et WeaveEventTriggers.

La sauvegarde des modifications s’effectue elle aussi en plusieurs étapes :

• On indique qu’on souhaite conserver les symboles de debugging
• On sauvegarde notre travail en remplaçant l’assembly original par celui que l’on vient d’instrumenter.

Jusqu’ici, tout va bien, comme qui dirait. Mais creusons un peu plus. Tout d’abord, le code de la méthode GetTypesToWeave qui nous permet de retourner les types de l’assembly à modifier. Il s’agit essentiellement d’alléger la méthode Run en évitant les imbrications et en isolant la logique de recherche dans une autre méthode :

private IEnumerable<TypeDefinition> GetTypesToWeave()
{
    string attributeFullName = typeof (NotifyPropertyChangedAttribute).FullName;
    foreach (TypeDefinition type in this.assembly.MainModule.Types)
    {
        foreach (CustomAttribute attribute in type.CustomAttributes)
        {
            if (attribute.Constructor.DeclaringType.FullName == attributeFullName)
            {
                yield return type;
                break;
            }
        }
    }
}

Notez qu’on utilise pour cela un bloc itérateur. Le reste pourrait se passer de commentaire : on retourne les types marqués par l’attribut [NotifyPropertyChanged] en basant la recherche sur le fullname des attributs.

Passons maintenant à la modification des types. Rappelez-vous, il y a deux étapes principales :

• Implémentation de INotifyPropertyChanged (méthode WeaveINotifyPropertyChanged)
• Instrumentation des setters (méthode WeaveEventTriggers)

Implémentation de INotifyPropertyChanged

L’implémentation proprement dite de INotifyPropertyChanged est une tâche que l’on peut aisément redécomposer. Cette redécomposition est d’ailleurs assez visible dans la méthode WeaveINotifyPropertyChanged que je propose :

private MethodReference WeaveINotifyPropertyChanged(TypeDefinition type)
{
    TypeReference iNotifyPropertyChangedType = GetReference<INotifyPropertyChanged>();
    type.Interfaces.Add(iNotifyPropertyChangedType);
    FieldReference eventField = WeaveEvent(type);
    
    return WeaveEventFiringHelper(eventField, type);
}

La première étape consiste à récupérer une TypeReference correspondant à cette interface pour l’ajouter à la liste des interfaces du type que l’on modifie. Simple, mais insuffisant : il faut également implémenter l’interface. Dans le cas d’INotifyPropertyChanged, on doit ajouter un évènement public PropertyChanged au type. C’est la méthode WeaveEvent qui s’en chargera. (Etape [#1] du schéma)

La méthode WeaveEventFiringHelper, quant à elle, permet d’ajouter une méthode FirePropertyChanged au type. Quelque chose équivalent à :

    private void FirePropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }

C’est l’étape [#2] de la transformation, également signalée dans le schéma précédent. La référence vers cette méthode est retournée pour permettre son appel plus tard à partir des setters des propriétés.

Dès que vous aurez terminé de bailler, nous détaillerons la première étape qui consiste à ajouter l’évènement PropertyChanged au type. Soit la méthode WeaveEvent :

private FieldReference WeaveEvent(TypeDefinition type)
{
    TypeReference eventHandlerTypeRef = GetReference<PropertyChangedEventHandler>();
    MethodReference combineMethodRef = this.assembly.MainModule.Import(combineMethodBase);
    MethodReference removeMethodRef = this.assembly.MainModule.Import(removeMethodBase);
    const string eventName = "PropertyChanged";

    FieldDefinition eventField = new FieldDefinition("PropertyChanged",
                                                     eventHandlerTypeRef,
                                                     FieldAttributes.Private);
    type.Fields.Add(eventField);

    EventDefinition eventDefinition = new EventDefinition(eventName,
                                                          eventHandlerTypeRef,
                                                          0);

    eventDefinition.AddMethod = CreateEventMethod(string.Format("add_{0}", eventName),
                                                  combineMethodRef,
                                                  eventField);

    eventDefinition.RemoveMethod = CreateEventMethod(string.Format("remove_{0}", eventName),
                                                     removeMethodRef,
                                                     eventField);

    type.Methods.Add(eventDefinition.AddMethod);
    type.Methods.Add(eventDefinition.RemoveMethod);
    type.Events.Add(eventDefinition);

    return eventField;
}

Le layout n’est pas terrible, j’espère que vous ne m’en tiendrez pas rigueur.

Petit rappel : Lorsqu’on est au niveau CIL, on a une bonne visibilité sur ce qu’un langage de plus haut niveau comme C# peut nous cacher. Les évènements constituent un bon exemple. En C#, la déclaration d’un event est simple :

public event PropertyChangedEventHandler PropertyChanged;

Au niveau IL, le compilateur C# va en fait générer un champ privé encapsulé par une propriété un peu spéciale de type event qui possède les méthodes « add » et « remove« . Note : même si ce n’est pas souvent utilisé, sachez qu’à partir de C# il est possible de faire apparaitre ces méthodes pour éventuellement intercepter les abonnements / désabonnements à l’évènement.

Pour ajouter l’évènement PropertyChanged à notre type, nous avons donc :

• Ajouté un champ d’instance privé de type NotifyPropertyChangedEventHandler
• Ajouté l’évènement (pseudo propriété), qui utilise deux méthodes : add_PropertyChanged et remove_PropertyChanged
• Créé les deux méthodes précédentes, qui utilisent respectivement les méthodes statiques Delegate.Combine et Delegate.Remove pour ajouter et supprimer les handlers au champ d’instance

Puisque l’IL n’est pas très lisible, voici la traduction C# de ces deux méthodes :

public void add_PropertyChanged(PropertyChangedEventHandler value)
{
    this.PropertyChanged = 
		(PropertyChangedEventHandler) Delegate.Combine(this.PropertyChanged, value);
}

public void remove_PropertyChanged(PropertyChangedEventHandler value)
{
    this.PropertyChanged = 
		(PropertyChangedEventHandler) Delegate.Remove(this.PropertyChanged, value);
}

Dans notre exemple précédent, on délègue la création de ces deux méthodes à CreateEventMethod dont voici la définition :

private MethodDefinition CreateEventMethod(string methodName,
                                           MethodReference delegateMethodReference,
                                           FieldReference eventField)
{
    const MethodAttributes attributes = MethodAttributes.Public |
                                        MethodAttributes.HideBySig |
                                        MethodAttributes.Final |
                                        MethodAttributes.SpecialName |
                                        MethodAttributes.NewSlot |
                                        MethodAttributes.Virtual;

    TypeReference eventHandlerTypeRef = GetReference<PropertyChangedEventHandler>();
    TypeReference voidType = GetReference(typeof (void));

    MethodDefinition methodDef = new MethodDefinition(methodName, attributes, voidType);


    methodDef.Parameters.Add(new ParameterDefinition(eventHandlerTypeRef));
    CilWorker cilWorker = methodDef.Body.CilWorker;
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Ldarg_1);
    cilWorker.Emit(OpCodes.Call, delegateMethodReference);
    cilWorker.Emit(OpCodes.Castclass, eventHandlerTypeRef);
    cilWorker.Emit(OpCodes.Stfld, eventField);
    cilWorker.Emit(OpCodes.Ret);
    return methodDef;
}

Notez l’API intuitive que propose Cecil pour ce genre de choses : on instancie une définition de l’élément que l’on cherche à ajouter au type (FieldDefinition, EventDefinition, MethodDefinition, etc.), on la configure si besoin, et on l’ajoute à la définition parente. Pour ce qui est de l’émission d’IL pour le corps des méthodes, il suffit d’obtenir un CilWorker et de créer séquentiellement les instructions en utilisant les codes d’opérations du langage intermédiaire.

Voilà pour la création de l’évènement PropertyChanged. Notre type est à présent une implémentation valide de l’interface INotifyPropertyChanged, puisque qu’il respecte le contrat imposé par cette dernière : exposer un évènement PropertyChanged, de type PropertyChangedEventHandler. (Etape [#1] du schéma)

Il ne reste plus qu’à déclencher cet évènement, et pour cela, il est habituellement préférable de prévoir une méthode spécifique qui sera appellée à partir des setters (Etape [#2]). Nous l’appellons ici FireNotifyPropertyChanged et c’est la méthode WeaveEventFiringHelper de notre transformer qui se charge de l’ajouter au type instrumenté :

private MethodReference WeaveEventFiringHelper(FieldReference eventField, TypeDefinition type)
{
    MethodReference invokeMethodRef = this.assembly.MainModule.Import(invokeMethodBase);
    MethodReference argsCtorMethodRef = this.assembly.MainModule.Import(constructorMethodBase);
    TypeReference stringTypeRef = GetReference<string>();
    TypeReference voidTypeRef = GetReference(typeof (void));

    MethodDefinition firePropertyChanged = 
        new MethodDefinition("FirePropertyChanged", MethodAttributes.Private, type);
    firePropertyChanged.ReturnType = new MethodReturnType(voidTypeRef);
    ParameterDefinition propertyNameParameter =
        new ParameterDefinition("propertyName", 0, ParameterAttributes.None, stringTypeRef);
    firePropertyChanged.Parameters.Add(propertyNameParameter);

    CilWorker cilWorker = firePropertyChanged.Body.CilWorker;

    Instruction returnInstruction = cilWorker.Create(OpCodes.Ret);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Brfalse_S, returnInstruction);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldarg_1);
    cilWorker.Emit(OpCodes.Newobj, argsCtorMethodRef);
    cilWorker.Emit(OpCodes.Callvirt, invokeMethodRef);
    cilWorker.Append(returnInstruction);
    type.Methods.Add(firePropertyChanged);

    return firePropertyChanged;
}

La FieldReference récupérée en argument est celle retournée par la méthode précédente, WeaveEvent, qui a ajouté l’évènement au type. Elle représente d’ailleurs le champ de l’évènement, qui doit être utilisé pour l’invocation. La traduction C# de la méthode générée dynamiquement correspond à :

    private void FirePropertyChanged(string propertyName)
    {
        if (this.PropertyChanged != null)
        {
            this.PropertyChanged.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
    }

C’est complètement équivalent au code de l’étape [#2] dans le premier schéma.

Instrumentation des setters

A ce stade, pour résumer, nous avons :

• [#1] Implémenté INotifyPropertyChanged en ajoutant un évènement PropertyChanged au type
• [#2] Créé une méthode « helper » pour déclencher l’évènement

Très logiquement, il ne reste plus qu’à appeller cette dernière à partir de tous les setters des propriétés du type que l’on modifie (étape [#3]). Cette fois-ci, on ne va pas créer un nouveau champ, un nouvel évènement ou une nouvelle méthode, on va modifier le code CIL du corps de méthodes existantes. Car un setter de propriété est une méthode traditionnelle.

Examinons la méthode WeaveEventTriggers du transformer, qui est responsable de cette tache :

private static void WeaveEventTriggers(TypeDefinition type, MethodReference firePropertyChanged)
{
    foreach (PropertyDefinition property in type.Properties)
    {
        MethodDefinition method = property.SetMethod;
        if (method == null)
        {
            continue;
        }

        Instruction retInstruction = method.Body.Instructions[method.Body.Instructions.Count - 1];

        CilWorker cilWorker = method.Body.CilWorker;
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Ldarg_0));
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Ldstr, property.Name));
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Call, firePropertyChanged));
    }
}

Encore une fois, l’implémentation est naïve et nous verrons s’il est possible de l’améliorer plus tard. La logique est simple :

• On itère sur toutes les propriétés du type. (Pas très malin…)
• On récupère la définition de la méthode du setter.
• On récupère une référence vers la dernière instruction du corps du setter
• On injecte le code CIL correspondant à l’appel de la méthode FirePropertyChanged avant la dernière instruction pour que la notification soit lançée à la fin de chaque modification.

En gros, si le setter en C# est du genre :

	public void set_Name(string value)
	{
		this.name = value;
	}

On le transforme en :

	public void set_Name(string value)
	{
		this.name = value;
		FirePropertyChanged("Name");
	}

Note : combineMethodBase, invokeMethodBase, constructorMethodBase et removeMethodBase, référencés dans les méthodes du Transformer, sont des membres statiques initialisés de la façon suivante :

private static readonly MethodBase combineMethodBase;
private static readonly MethodBase invokeMethodBase;
private static readonly MethodBase constructorMethodBase;
private static readonly MethodBase removeMethodBase;

static Transformer()
{
    var type = typeof (Delegate);
    combineMethodBase = type.GetMethod("Combine", new[] {type, type});
    removeMethodBase = type.GetMethod("Remove");
    type = typeof (PropertyChangedEventHandler);
    invokeMethodBase = type.GetMethod("Invoke");
    type = typeof (PropertyChangedEventArgs);
    constructorMethodBase = type.GetConstructor(new[] {typeof (string)});
}

Les MethodBase sont des types de l’API d’introspection de System.Reflection. Il est facile de récupérer les MethodReference correspondantes (API Cecil) en utilisant la méthode Import d’une ModuleDefinition.

Conclusion intermédiaire

Voilà une première version du « transformer » capable d’instrumenter un assembly existant pour faire implémenter INotifyPropertyChanged à certains de ses types automatiquement. Les améliorations possibles sont nombreuses, et je ne vais en citer que quelques unes :

• Meilleure utilisation de Cecil : après tout, je découvre et suis donc loin d’être un expert
• Meilleure intégration au process de build, en utilisant une custom task MSBuild par exemple
• Version complète de l’instrumentation : l’évènement PropertyChanged ne doit être déclenché que lorsque la valeur affectée à la propriété est différente
• Gestion des exceptions et du logging (évidemment)
• Etc.

Cecil est un outil extrêmement puissant et facile d’utilisation. Pour info, la mise en place de cette version du Transformer n’a pas dû me prendre 2 heures, alors que la femme de ma vie me parlait je faisais autre chose en même temps, et que je découvrais complètement l’API non documentée. Il est préférable par contre de connaître le CIL, même si ILdasm ou Reflector peuvent vous assister efficacement. Enfin, et presque paradoxalement, la prise en main de Cecil vous paraitra déroutante si vous avez l’habitude d’utiliser System.Reflection et System.Reflection.Emit.

Au final ma première expérience est définitivement positive, et je n’hésiterai pas dans le futur à recourir à Cecil au besoin. Je pense d’ailleurs qu’en collaboration avec une couche facilitant son utilisation dans un context post-build, on aurait quelque chose d’assez terrible, probablement plus simple à utiliser que PostSharp.Core par exemple pour des tâches bien spécifiques.

Notez tout de même que l’exemple d’utilisation de Cecil présenté ici est un peu tordu, et qu’il y a bien d’autres (meilleurs) moyens d’exploiter ses capacités.