Cette année je continuerai mon implication dans les forums MSDN et j’essayerai de publier beaucoup plus d’article sur mon blog !

Ce post fait partie d’une série de post consacré à Code Contracts :

• Partie 01 – Introduction
• Partie 02 – Les pré-conditions
• Partie 03 – Les post-conditions
• Partie 04 – Les invariants

Qu’est ce qu’un invariant ?

Un invariant est contrat qui doit toujours être vérifié durant la vie d’un objet. On utilise le plus souvent les invariants pour valider constamment la validité d’une propriété publique d’une classe.

Comme pour les post-conditions, les invariants permettent de “rassurer” un intégrateur qu’une condition sur une propriété sera toujours vérifiée après chaque appel à une méthode ou getter/setter d’une propriété “publique” de la classe (publique pour l’intégrateur, cela peut donc être les méthodes et propriétés public ou protected).

Comment définir un invariant ?

Pour définir un invariant, il faut créer une méthode privée marquée de l’attribut ContractInvariantMethodAttribute qui contiendra les différents contrats (invariants). Pour spécifier un invariant, il faut utiliser la méthode Contract.Invariant() et spécifier une condition qui devra toujours être vérifiée.

L’exemple suivant illustre la définition d’un invariant sur la classe CompteBancaire afin que le Solde soit toujours supérieur à 0.

public class CompteBancaire
{
    public decimal Solde
    {
        get;
        private set;
    }

    public void Créditer(decimal montant)
    {
        this.Solde += montant;
    }

    public void Débiter(decimal montant)
    {
        this.Solde -= montant;
    }

    [ContractInvariantMethod]
    private void MonInvariant()
    {
        Contract.Invariant(this.Solde > 0);
    }
}

Une fois compilée, la méthode MonInvariant() fait partie de la classe comme toute méthode privée classique. L’outil de réécriture modifiera automatiquement le code afin que la méthode soit appelée après chaque méthodes ou getter/setter publiques.

Si maintenant on exécute l’exemple suivant :

static void Main(string[] args)
{
    CompteBancaire cb = new CompteBancaire();
    cb.Créditer(100);
    cb.Débiter(200);
}

Comme pour les post-conditions une exception de type ContractException est automatiquement levée :

Les invariants ne valident pas les champs/propriétés privées !

Beaucoup d’exemples sur d’autres site web montrent des invariants qui valident les champs et les propriétés privées. Même si cela est techniquement possible, c’est complètement aberrant d’un point de vue conceptuel. En effet, les invariants sont des contrats qui seront visibles par les intégrateurs. Les conditions doivent donc définir des constantes sur des objets publiques !

Par exemple, si un intégrateur ne respecte pas un invariant qui fait référence à un champ privé, il peut obtenir un message d’erreur comme ceci :

Comment peut-il savoir que la variable “s” correspond au solde du compte bancaire ???

Les conditions des invariants doivent donc porter sur des propriétés visibles par les intégrateurs (public ou protected).

Ce post était consacré aux invariants, nous verrons dans le prochain comment définir des contrats sur les interfaces.

Stay tuned !

Ce post fait partie d’une série de post consacré à Code Contracts :

• Partie 01 – Introduction
• Partie 02 – Les pré-conditions
• Partie 03 – Les post-conditions
• Partie 04 – Les invariants

Qu’est-ce qu’une post-condition ?

Une post-condition permet de définir un contrat qui devra être respecté avant de sortir d’une méthode (ou d’un getter/setter d’une propriété). Les post-conditions doivent être vue comme un contrat ou une assurance qu’un développeur va exposer aux appelants d’une méthode.

Code Contracts permet de définir 4 types de post-conditions :

• Sur la valeur de retour d’une méthode
• Sur la valeur d’un paramètre de sortie d’une méthode (paramètre de type out)
• Sur la valeur précédente (initiale) d’une propriété ou d’un paramètre d’une méthode.
• Sur la valeur d’une propriété ou d’un paramètre après la levée d’une exception dans une méthode

Les post-condition ne servent pas d’assertion !

Lorsque je présente les post-conditions, les développeurs sont souvent tentés d’utiliser les post-conditions comme un outil permettant de contrôler le retour d’une méthode. Bien que c’est le but de l’outil de ré-écriture ccrewriter, ce n’est vraiment pas la philosophie des post-conditions de Code Contracts.

Une post-condition doit-être vue comme un message que l’on souhaite passer au développeur qui utilisera notre méthode (ou à l’appelant). Si on prend comme exemple l’affirmation suivante : “L’appel de la méthode M() retournera toujours une référence vers un objet (plus techniquement la référence retournée ne sera jamais nulle)”. Le développeur (ou l’intégrateur) qui utilisera la méthode M(), sera qu’il n’est pas nécessaire de tester la nullité de la référence récupérée par la méthode M().

Contrairement aux pré-conditions, si le contrat n’est pas validé, ce n’est pas la faute de l’appelant mais au concepteur de la méthode !

Comment définir une post-condition ?

Code Contracts permet de définir très simplement une post-condition à l’aide de la méthode Contract.Ensures(). Cette méthode doit-être spécifiée au début du corps de la méthode avec les pré-conditions.

Comme pour les pré-conditions, la méthode Contract.Ensures() prend en paramètre la condition à vérifier et si nécessaire un message explicatif associé.

L’exemple suivant, montre une post-condition qui garanti que la propriété MonObjet fera référence à un objet.

public class MonObjet
{
    public string Message
    {
        get;
        private set;
    }

    public void RemplirMessage()
    {
        Contract.Ensures(this.Message != null);

        this.Message = "Hello !";
    }
}

Comme pour les pré-conditions, il faut voir les appels à la méthode Contract.Ensures() comme des méta-données. Ce sont les outils lancées après la compilation qui permettront d’interpréter ce genre de contrats.

En utilisant l’exemple précédent, il est donc possible d’appeler la méthode RemplirMessage() et d’utiliser directement la propriété Message sans tester sa nullité.

MonObjet instance = new MonObjet();
instance.RemplirMessage();

char c = instance.Message[0];

Si maintenant on active l’outil de ré-écriture de Code Contracts (je vous invite à consulter mon post précédent pour plus d’informations) et que le contrat n’est pas valide (c’est à dire si la propriété Message est à null en sortie de la méthode) on obtiendra l’exception suivante :

Définir une post-condition sur la valeur de retour d’une méthode.

Code Contracts permet de définir des post-conditions sur la valeur de retour d’une méthode. Pour cela il faut utiliser la méthode Contract.Result<T>(), avec T le type de retour de la méthode.

La méthode Contract.Result<T>() est une méta-données qui représente la valeur de retour de la méthode courante. L’exemple suivant illustre une méthode GetClients() retournant un tableau de client qui ne doit pas être null :

public Client[] GetClients()
{
    Contract.Ensures(Contract.Result<Client[]>() != null);

    return new Client[]
    {
        new Client() { Nom = "TOURREAU" }
    };
}

Ce genre de post-condition apporte une information importante pour l’appelant. En effet, le résultat de l’appel de la méthode GetClients() peut-être directement utilisé dans une boucle de type foreach car le tableau obtenu ne sera jamais null (une vérification de l’existence d’un tableau n’est donc pas nécessaire au niveau de l’appelant).

MonObjet instance = new MonObjet();

foreach (Client client in instance.GetClients())
{
    Console.WriteLine(client.Nom);
}

Définir une post-condition sur un paramètre de sortie d’une méthode.

Code Contracts offre une méthode Contract.ValueAtReturn() permettant de définir des post-conditions sur des paramètres de sortie d’une méthode (paramètre de type out) :

public void GetMessage(out string message)
{
    Contract.Ensures(Contract.ValueAtReturn(out message) != null);

    message = "Hello !";
}

Dans cet exemple, la post-conditions définie permet d’assurer à l’appelant que le paramètre de sortie message sera toujours différent de null.

Définir une post-condition sur la valeur précédente d’un paramètre ou d’une propriété.

Code Contracts offre une fonctionnalité très puissante permettant de définir des post-conditions sur les valeurs initiales d’un paramètre ou d’une propriété. La méthode Contract.OldValue<T>() représente une méta-données qui correspond à la valeur initiale d’un paramètre ou d’une propriété.

L’outil de ré-écriture ccrewriter s’occupera d’insérer les variables temporaires permettant de comparer les valeurs des paramètres ou des propriétés au début et à la fin de l’appel à une méthode.

Imaginons une classe contenant un compteur (propriété) et une méthode qui affiche et incrémente ce compteur. Il serait intéressant dans la méthode d’exposer une post-condition qui indique que la valeur du compteur aie bien été incrémentée :

public class MonObjet
{
    public int Compteur
    {
        get;
        set;
    }

    public void Compter()
    {
        Contract.Ensures(Contract.OldValue(this.Compteur) + 1 == this.Compteur);

        Console.WriteLine(this.Compteur);

        this.Compteur++;
    }
}

Définir une post-condition sur la valeur d’un paramètre ou d’une propriété après la levée d’une exception.

Code Contracts permet de définir une post-condition sur un paramètre ou une propriété après la levée d’une exception. Cela est très pratique pour indiquer à l’appelant que certaines propriétés ne sont pas modifiées ou sont réinitialisée en cas de levée d’une exception.

Pour définir ce genre de post-condition il faut utiliser la méthode Contract.EnsuresOnThrow<T>() avec T le type d’exception qui doit être déclenché pour vérifier la condition.

public class MonObjet
{
    public string Message
    {
        get;
        set;
    }

    public void UpdateMessage(bool déclencherException)
    {
        Contract.EnsuresOnThrow<InvalidOperationException>(this.Message == null);

        if (déclencherException == true)
        {
            this.Message = null;
            throw new InvalidOperationException();
        }

        this.Message = "Hello !";
    }
}

Dans l’exemple précédent, l’appelant peut avoir l’assurance que la propriété Message sera à null si la méthode UpdateMessage() déclenche une exception de type InvalidOperationException.

Ce post était consacré aux post-conditions, nous verrons dans le prochain les invariants.

Stay tuned !

Ce post fait partie d’une série de post consacré à Code Contracts :

• Partie 01 – Introduction
• Partie 02 – Les pré-conditions
• Partie 03 – Les post-conditions
• Partie 04 – Les invariants

Qu’est ce qu’une pré-condition ?

Une pré-condition est un contrat que doit respecter un appelant pour utiliser une méthode où une propriété. Le plus souvent les pré-conditions permettent de contrôler les paramètres d’une méthode, mais on peut les utiliser pour définir des contrats sur l’état que doit avoir un objet lors de l’appel à une méthode.

Comment définir une pré-condition ?

Code Contracts permet de définir très simplement un contrat à l’aide de la méthode Contract.Requires() :

public static double Diviser(int dividende, int diviseur)
{
    Contract.Requires(diviseur != 0, "Le diviseur ne peut pas être égale à 0");

    return dividende / diviseur;
}

Le premier paramètre est une expression booléenne qui représente le contrat et qui doit toujours être vrai pour que le contrat soit respecté. Le deuxième paramètre est une chaine de caractères qui représente une message d’erreur à afficher si le contrat n’est pas respecté.

Il est possible de spécifier plusieurs contrats, dans ce cas il faudra les spécifier les uns à la suite des autres. Il est aussi tout à fait possible de spécifier plusieurs contrats portant sur le même paramètre :

public static void Afficher(string nom, int age)
{
    Contract.Requires(nom != null);
    Contract.Requires(nom.Length > 3);
    Contract.Requires(1 <= age && age <= 99);

    Console.WriteLine("{0} : {1}", nom, age);
}

La méthode Contract.Requires() doit-être vue comme des méta-données…

La méthode Contract.Requires() ne doit pas être vu comme une méthode qui exécute du code, mais comme des méta-données de la méthode Diviser() (exactement comme des attributs .NET).

En effet, si on exécute la méthode Diviser() avec un diviseur à 0, aucun mécanisme de sécurité sur le contrat n’est déclenché. Le code continue son exécution jusqu’à levée une exception au niveau de la division par 0.

Pourtant si l’on regarde le code généré on se rend très vite compte que l’appel à la méthode Contract.Requires() a disparu :

Pourquoi ? Tout simplement parce qu’elle dispose d’un attribut conditionnel spécifiant que la macro CONTRACTS_FULL doit-être défini au moment de la compilation.

Si on défini la macro CONTRACTS_FULL dans les propriétés de projet…

Et que l’on relance l’application, un message d’avertissement apparait :

Ce message indique qu’il est nécessaire d’utiliser un outil de réécriture lorsque l’on utilise les pré-conditions à l’aide de Contract.Requires(). ccrewriter est l’un des outils inclus de Code Contracts qui permet de transformer les appels de la méthode Contract.Requires() en levée d’exception .NET.

L’activation de l’outil de réécriture ccrewriter se fait depuis l’onglet Code Contracts dans les paramètres de projet. Il suffit d’activer l’option “Perform Runtime Contract Checking” à “Full”. (Nous verrons plus en détail un peu plus-tard les options disponibles dans les paramètres de projet).

Après recompilation, une exception de type ContractException est levée si le diviseur passé en paramètre est égal à 0 :

Déclenchez une exception d’un autre type

Il existe une surcharge de la méthode Contract.Requires() qui est générique et qui permet de déclencher une exception autre que ContractException. Le type de l’exception à déclencher doit-être spécifié en paramètre de type à la méthode Contract.Requires(). Dans notre cas, si on veut lever une exception de type ArgumentException en cas de non respect de notre contrat, il faut écrire :

public static double Diviser(int dividende, int diviseur)
{
    Contract.Requires<ArgumentException>(diviseur != 0, "Le diviseur ne peut pas être égal à 0");

    return dividende / diviseur;
}

Pour que ce code puisse être compilé et réécrit avec ccrewriter, il est nécessaire de définir l’option “Assembly Mode” à “Standard Contract Requires” dans les propriétés du projet.

Après compilation, on obtient à l’exécution, la levée d’une exception de type ArgumentException lors que le diviseur passé en paramètre est à 0 :

Contrôler les paramètres de type IEnumerable<T> (ForAll() et Exists())

La classe Contract contient deux méthodes ForAll() et Exists() permettant de contrôler des éléments se trouvant dans une séquence de type IEnumerable<T>.

• La méthode ForAll() vérifie que tous les éléments d’une séquence respecte la condition spécifiée en paramètre.
• La méthode Exists() vérifie qu’au moins un élément d’une séquence respecte la condition spécifiée en paramètre.

Ces méthodes peuvent être vues comme un moyen simple de faire une simple boucle foreach dans des contrats. Dans les deux cas, les conditions sont spécifiés à l’aide d’une lambda expression. L’exemple qui suit montre comment vérifier que les éléments d’une séquence de noms ne soient pas null, vide ou contenant des espaces. Remarquez qu’il ne faut pas oublier d’ajouter un contrat permettant de vérifier que l’énumération passé en paramètre n’est pas null.

public static void Afficher(IEnumerable<string> noms)
{
    Contract.Requires<ArgumentException>(noms != null);
    Contract.Requires<ArgumentException>(Contract.ForAll(noms, nom => string.IsNullOrWhiteSpace(nom)) == false);

    foreach (string nom in noms)
    {
        Console.WriteLine(nom);
    }
}

Si l’on passe en paramètre une séquence (par exemple un tableau) contenant une chaine nulle ou vide on obtiendra l’exception suivante :

Il existe une surcharge supplémentaires pour les méthodes ForAll() et Exists() qui permettent d’incrémenter une variable et de vérifier une condition à chaque itération. Ces surcharges peuvent être vues comme un moyen de réaliser une boucle for dans des contrats. L’exemple suivant montre comment contrôler que tous les nombres d’un tableau spécifié en paramètre sont des nombres paires :

public static void Afficher(int[] t)
{
    Contract.Requires<ArgumentException>(t != null);
    Contract.Requires<ArgumentException>(Contract.ForAll(0, t.Length, i => t[i] % 2 == 0));

    foreach (int nombre in t)
    {
        Console.WriteLine(nombre);
    }
}

Fini le blabla ! Laisser parler votre code !

Une des forces de Code Contracts est la possibilité d’inclure la condition des contrats dans les messages d’erreur. Plus précisément, c’est l’outil de réécriture ccrewriter qui prend la condition booléenne C# et en fait une chaine de caractères pour l’inclure dans les messages d’erreur.

Ainsi, il n’est plus nécessaire d’écrire, de traduire et de maintenir une chaine de caractères représentant le message d’erreur affiché lorsqu’un contrat n’est pas valide.

Ce mécanisme permet d’avoir un certain “typage fort” entre vos contrats et les messages d’erreurs associés. En effet, si vous renommez un paramètre vous serai obligé de modifier les conditions des contrats associés (sinon la compilation est impossible). Il n’est donc plus nécessaire de modifier des chaines de caractères.

L’exemple suivant montre le code de la méthode Diviser() en supprimant le message d’erreur associé au contrat qui porte sur le diviseur :

public static double Diviser(int dividende, int diviseur)
{
    Contract.Requires<ArgumentException>(diviseur != 0);

    return dividende / diviseur;
}

A l’exécution, lorsque le contrat est invalide, l’appelant obtiendra l’exception suivante :

Ce post était consacré aux pré-conditions, nous verrons dans le prochain les post-conditions.

Stay tuned !

Ce post fait partie d’une série de post consacré à Code Contracts :

• Partie 01 – Introduction
• Partie 02 – Les pré-conditions
• Partie 03 – Les post-conditions
• Partie 04 – Les invariants

Depuis que je suis architecte, j’insiste énormément sur la qualité des développements et en particulier le fait de détecter les erreurs le plus rapidement possible (durant la phase de développement ! Et non à l’intégration, recette ou pré-production !).

A travers différents posts sur mon blog (au moins une quinzaine), je vais présenter cette technologie du .NET Framework 4.0 qui actuellement très peu utilisé, mais qui devrait être obligatoire d’utiliser dans tout développement logiciel sous .NET.

Qu’est ce qu’un contrat ?

Lorsque l’on regarde la documentation MSDN concernant les bibliothèques du .NET Framework, on se rend compte que Microsoft impose des contraintes que l’on doit respecter avant d’utiliser certaines fonctionnalités (par exemple l’appel à la méthode String.Substring()).

Si on regarde la capture précédente, les contraintes imposées par Microsoft pour utiliser la méthode String.Substring() sont surlignées en jaune. Cette contrainte est ce que l’on appel un contrat.

Pourquoi imposer des contrats ?

Lorsqu’un développeur conçoit une classe, il offre une partie “publique” qui sera certainement utilisé par un autre développeur, qui au passage, n’est pas forcement dans la même équipe (par exemple un intégrateur). Etant donné que l’autre développeur n’a pas directement connaissance de l’implémentation de la classe, il est donc nécessaire de contrôler et documenter les appels à la partie publique à l’aide de contraintes (où plutôt contrats). Les contrats permettent d’assurer au développeur de la classe que les données d’entrées sont valides et n’auront pas d’effet secondaires sur l’exécution de la classe.

Lorsqu’un contrat n’est pas respecté, il n’est théoriquement pas possible d’effectuer une compilation. Si le compilateur ne supporte pas la vérification des contrats, alors l’exécution de l’application doit-être stoppée.

Que ce passe-t-il si on n’impose pas des contrats ?

Prenons l’exemple suivant :

On propose une méthode Traitement() prenant en paramètre une interface que doit implémenter un intégrateur. Cette interface contient une méthode GetObject() qui retourne un objet qui sera affiché dans une application Console.

Voici le code de cette interface :

public interface IObjectProvider
{
    object GetObjet();
}

Et le code de la méthode Traitement() qui prend en paramètre un objet implémentant l’interface précédente :

public class ConsoleDisplay
{
    public void Write(IObjectProvider provider)
    {
        object obj;

        obj = provider.GetObjet();

        Console.WriteLine(obj.ToString());
    }
}

Maintenant, imaginons que l’on compile et livre en Release la classe ConsoleDisplay et l’interface IObjectProvider à un intégrateur. Ce dernier va donc implémenter l’interface IObjectProvider comme ceci :

public class MyObjectProvider : IObjectProvider
{
    public object GetObjet()
    {
        return null;
    }
}

Voici maintenant un exemple d’utilisation de la classe ConsoleDisplay développé par l’intégrateur :

MyObjectProvider myProvider = new MyObjectProvider();
ConsoleDisplay display = new ConsoleDisplay();

display.Write(myProvider);

Si l’intégrateur exécute ce code, il obtiendra l’erreur suivante :

On obtient une exception de type NullReferenceException alors que les variables display et myProvider ne sont pas null. Le bug se trouve donc à l’intérieur de la méthode Write() (le StackTrace de l’exception nous donnera confirmation). Lorsque l’on obtient ce genre d’erreur, est-ce à l’intégrateur de le corriger ou à nous ? Bien évidemment, c’est à l’intégrateur… Mais comment peut-il savoir d’où vient le problème et comment le corriger ? Tout simplement en l’aidant à l’aide des contrats !

Ecrire des contrats avant le .NET Framework 4.0…

Du .NET Framework 1.0 jusqu’au 3.5 inclus, il était possible de définir des contrats sur les paramètres des méthodes en utilisant les exceptions :

public double Division(double dividende, double diviseur)
{
    if (diviseur == 0)
    {
         throw new ArgumentException("Le diviseur ne peut pas être à 0", "diviseur");
    }

    return dividende / diviseur;
}

Le code précédent déclenche une exception de type ArgumentException si le contrat n’est pas respecté (ici le diviseur ne doit pas être égal à 0). En production, la levée des exceptions dérivée de ArgumentException indique un bug dans l’application dû au passage d’un paramètre incorrect. Ce n’est donc pas à l’utilisateur final de corriger cette erreur, mais bien au développeur de l’application. Ce genre d’exception ne devrait donc jamais être interceptées dans un bloc try/catch.

Les avantages de Code Contracts

Si on regarde le code précédent, on se rend très vite compte de plusieurs inconvénients :

• Les contrats ne sont pas vérifiés à la compilation
• Le nom du paramètre est une chaine de caractère (pas de typage pour le refactoring)
• Les contrats ne sont pas hérités lors de la redéfinition d’une méthode (nécessite de dupliquer du code)
• Il est nécessaire de documenter explicitement les commentaires XML
• Il n’est pas possible de définir des contrats dans une interface (ou méthodes abstraites).
• Il n’est pas possible de supprimer les contrats en production

Code Contracts permet de palier à tous ces problèmes en offrant :

• La vérification des contrats à la compilation
• Le typage fort des contrats
• L’héritage des contrats dans la redéfinition des méthodes
• La documentation automatique des contrats en XML
• La possibilité de définir des contrats dans les interfaces (et méthodes abstraites)
• La possibilité de créer un assembly séparé contenant uniquement les contrats

Code Contracts propose en plus de :

• Définir des post-conditions
• Définir des invariants
• De redéfinir la politique de vérification des contrats
• De créer de nouveau contrats (agrégations de contrats)

Concept de Code Contracts

Code Contracts s’utilisent en 2 étapes :

• La première consiste à définir les contrats dans le code en utilisant les classes contenues dans le namespace System.Diagnostics.Contracts. Ces classes ne produisent aucun effet à l’exécution. Il faut donc voir les contrats comme des meta-données sur le code (exactement comme des attributs .NET).
• La deuxième étape consiste à exécuter un outil qui analysera les contrats contenu dans l’assembly compilé et qui produira en sortie différents résultats. Microsoft propose avec Code Contracts trois outils :
  • ccrewriter : Cet outils va convertir les contrats spécifiés dans un assembly compilé en un code .NET permetant de vérifier les contrats à la l’exécution.
  • cccheck : Cet outil va analyser un assembly et vérifier statiquement que tous les appelants respecte bien les contrats.
  • ccdoc : Cet outil va extraire les contrats et produire une documentation XML qui sera possible d’utiliser dans SandCastle.

Le schéma précédent montre un exemple d’utilisation de l’outil ccrewriter :

1. Les contrats sont définit dans le code C# et doit-être vu comme des méta-données
2. Après compilation, le contrats sont compilés mais ne produisent aucun effet
3. Après exécution de l’outil ccrewriter les contrats compilé sont transformé en bloc if/then/throw permettant de contrôler les contrats et lever une exception si ces derniers ne sont pas valides.

Bien évidemment, il y a de grande chance que Microsoft et d’autres éditeurs tiers fournissent d’autres outils. Il est d’ailleurs possible de créer un outil de ce genre en utilisant le projet open source Microsoft : Common Compiler Infrastructure.

La classe principale permettant de définir des contrats est la classe Contract. Elle contient un ensemble de méthodes qui permettent de définir des pré-conditions, des post-conditions et des invariants. J’insiste sur le fait que ces méthodes ne produisent aucun effet à l’exécution si on utilise les assemblys compilés tel quel. Il faudra lancer l’outil ccrewriter après la compilation afin de réécrire les assemblys compilés et transformer les contrats déclarés en un code qui réalisera des tests et lèvera des exceptions si les contrats ne sont pas respectés.

Ce qu’il faut pour utiliser Code Contracts

Les classes permettant de définir les contrats sont incluses dans le .NET Framework 4.0 (assembly System.dll), il est cependant possible d’utiliser Code Contracts avec le .NET Framework 3.5 utilisant l’assembly Microsoft.Contracts qui peut-être téléchargé sur le site de Microsoft.

Les outils de réécriture et d’analyse de code ne sont pas fourni avec le .NET Framework ni avec Visual Studio. Il faudra télécharger ces outils sur le site officiel de code Code Contract sur le site de Microsoft Research : http://research.microsoft.com/en-us/projects/contracts/

L’équipe de Code Contracts propose aussi une extension pour Visual Studio 2010 qui propose des snippets de code et l’affichage des contrats dans l’info-bulle de l’éditeur de code.

Une fois les outils installé, le paramétrage de ccrewriter, cccheck et ccdoc se font depuis les propriétés du projet :

Si vous disposez d’une version Premium ou Ultimate de Visual Studio, vous avez la possibilité d’activer la vérification statique du code.

Dans les posts suivants, nous verront comment définir et activer des contrats avec Code Contracts.

Stay tuned !

Je me ferai un plaisir de répondre à vos questions concernant les technologies Microsoft durant les pauses. Pour me reconnaitre, j’aurai un T-Shirt où sera inscrit “Ask To Expert”.

Je vous invite à vous y rendre et à assister aux différentes sessions et en particulier celle dédiées aux dernières technologies Microsoft comme Windows Phone, Office 365 et Windows Azure.

Pour vous rendre aux Microsoft Days 2011, il est nécessaire de s’inscrire sur le site de Microsoft à la rubrique dédié aux Microsoft Days 2011.

Comme son nom l’indique, CCI Explorer se base sur le projet open source “Common Compiler Infrastructure” de Microsoft qui permet de décompiler et d’analyser du code depuis des assemblys .NET. Ce projet est utilisé par FxCop/Code Analysis, Sand Castle et Code Contracts.

Bien évidemment le projet en est à sa première version alpha, il manque donc plein de fonctionnalités, mais vous pouvez soumettre vos retours directement sur le site du projet.

Voici le lien pour télécharger la version 0.1.0.

Code Contracts est une nouveauté du .NET Framework 4.0 qui permet de définir des contraintes qui seront validées à l’exécution et/ou à la compilation !

Venez donc découvrir dans cette session les différents types de contrôles que vous pourrez mettre en place (pré-conditions, post-conditions,…etc) et comment ils vont améliorer la qualité de votre application !

Après les TechDays, Amine et moi-même rédigerons très certainement plusieurs articles sur Code Contracts.

Accéder à la page officielle de la session sur Code Contracts

Cette année je continuerai mon implication dans les forums MSDN et j’essayerai de publier beaucoup plus d’article sur mon blog !

Ce livre est destiné aux développeurs qui connaissent déjà les bases de la programmation et qui souhaitent apprendre très vite le C# 2.0, 3.0, 3.5 et 4.0.

L’objectif de ce titre de la collection des Guides de survie est de présenter les fonctionnalités et les concepts de base de C# aux développeurs familiers de la programmation. Il peut être lu de manière linéaire, mais il est possible de lire isolément un passage ou un chapitre particulier. Par ailleurs, les sections de ce livre sont conçues pour être indépendantes : il n’est donc pas nécessaire de lire les sections précédentes pour comprendre les différents exemples de code d’une section donnée.

Cliquez sur le livre pour le commander

Son prix est de 19€. Vous pouvez l’acheter directement sur Amazon.

ISBN : 978-2-7440-2432-0

Au sommaire :

1. Éléments du langage
2. Les classes
3. L’héritage
4. La gestion des erreurs
5. Les génériques
6. Les chaînes de caractères
7. LINQ (Language Integrated Query)
8. Les classes et interfaces de base
9. Les collections
10. Les flux
11. Les fichiers et répertoires
12. Les threads
13. La sérialisation
14. L’introspection

Je tiens à remercier les Editions Person pour m’avoir permis de vivre l’aventure qu’à été la rédaction de cet ouvrage ainsi que Nicolas ETIENNE et Jean-Philippe MOREUX pour leur relecture.