Analyser du code .Net avec FxCop

Programmer, c'est comme écrire, il y a ceux qui ont du style, ceux qui n'en ont pas, ceux qui font des fautes, et les autres. Même si tout langage de programmation, et toute technologie imposent des contraintes, des syntaxes et des règles précises, il n'empêche que la même application écrite par dix développeurs différents ne sera jamais exactement la même. Chaque personne à une manière différente de tourner des algorithmes, de nommer des variables ou je ne sais encore quel détail qui fait le style d'un développeur. Cependant, même si un code ne peut pas être strictement prédéfini, il doit quand même satisfaire un certain nombre d'exigences, en termes de design et de syntaxe. Toutes ces règles et normes sont définies pour apporter le meilleur niveau de performance et de standardisation possible aux applications. Il faut prendre ces termes au sens large, en effet, cela concerne les performances brutes, mais aussi la sécurité, les conventions de nommage, le design… Toutes ces mesures qui font qu'un programme est écrit dans les règles de l'art ou non. Rares, voire inexistants, sont les développeurs capables d'écrire ce code « parfait » au premier jet, sans avoir à y revenir.

Ces règles et nomenclatures sont nombreuses, et parfois complexes. De plus, celles-ci ne sont pas gravées dans le marbre, et de ce fait peuvent évoluer, ou être différentes d'une société à une autre. Cet ensemble fait qu'il est complexe, coûteux en temps et peu motivant de parcourir ses lignes de code à la recherche des éléments à modifier pour se conformer aux différentes exigences. Et une fois de plus, le développeur a trouvé la parade, une application est capable de faire cela ! Elle se nomme FxCop. Bien entendu, ce n'est pas la seule application capable de réaliser une telle analyse, mais c'est l'une des plus connues, elle est gratuite, performante, et issue de la communauté des développeurs .Net. C'est donc pour toutes ces raisons que j'ai choisi de la présenter. J'avoue l'utiliser depuis quelques mois seulement, mais, elle me rend de fiers services en me procurant un code plus simple à maintenir, en évitant les grosses fautes, pouvant notamment avoir un impact sur les performances ou la sécurité d'une application. Avant de voir plus en détail FxCop, voyons tout d'abord où trouver ce logiciel, et comment l'installer.

FxCop, à l'heure où j'écris ces lignes est en version 1.35, et nécessite le Framework .Net 2.0. Cette version est capable d'analyser des assemblies issues de toutes les versions du Framework inférieures ou égales à la 2.0. Mais gageons que l'équipe de développement de FxCop saura réagir et adapter cet outil à la sortie prochaine du Framework 3.0, qui se fera parallèlement à la sortie de Windows Vista. Cet outil, gratuit je le rappelle, est disponible sur le site de GotDotNet. Par rapport à la version précédente (1.32), la 1.35 corrige plus de 150 bugs, rectifie certaines règles pouvant donner des résultats erronés, et ajoute cinq nouvelles règles.

Cet outil est disponible en téléchargement (environ 3.6 Mo) à cette adresse : http://www.gotdotnet.com/team/FxCop/.

Pour l'installation même du programme, vous allez voir, il n'y a rien de compliqué, c'est juste du « next next OK »… Bref, à la portée de tout le monde. Le seul prérequis est le Framework .Net 2.0, en effet cette dernière version en a besoin pour s'exécuter. Vous admettrez que pour une application dont le but est d'analyser des assemblies .Net cela n'a rien de révoltant. Voici quelques captures d'écrans de l'installation :

Tout d'abord je vais vous présenter FxCop et ses fonctionnalités dans les grandes lignes. Histoire de comprendre comment il fonctionne, ce que l'on peut en attendre ou non. Premièrement, vous devez savoir que cet outil travaille sur des assemblies « compilées » et non sur le code source, c'est-à-dire que son domaine de prédilection c'est le MSIL et non le VB.Net, C#, ou encore Delphi.Net… Ce détail a son importance, travaillant sur des assemblies et non sur du code source, FxCop est totalement indépendant vis-à-vis du langage de que vous avez employé pour votre programme, du moment bien évidemment qu'il s'agit de .Net ! Mais est-ce bien utile de le préciser ?

Son principe de fonctionnement est le suivant : FxCop procède à une analyse méticuleuse du code MSIL d'une assembly, et vérifie que l'assembly est en conformité avec les règles qui lui sont associées. En effet, chaque point vérifié correspond en fait à une règle, qui, elle-même est issue des bonnes pratiques édictées par Microsoft. Bonnes pratiques, qui sont d'ailleurs publiquement connues, puisqu'en libre téléchargement sur le site MSDN. FxCop n'invente donc rien, mais compile et concentre en une seule application toutes ces bonnes pratiques. Quand on sait que la version 1.35 en contient plus de 200, on réalise alors la productivité apportée par un tel outil. Bien entendu, il est possible de choisir parmi toutes ces règles lesquelles doivent être vérifiées ou non, nous verrons même plus loin qu'il est possible de créer ses propres règles entièrement personnalisées. Une fois l'analyse complétée, dont la durée sera évidemment plus ou moins grande en fonction du nombre, de la taille, et de la complexité des assemblies chargées, un rapport est généré. Un premier tableau contient une liste comportant chaque anomalie détectée en précisant notamment le type, le niveau, le pourcentage de probabilité réelle du problème. D'autres informations sont également fournies, je vous laisse les découvrir. Le plus intéressant concerne la partie basse de l'interface qui contient le détail de l'anomalie sélectionnée. Ici ce sont des informations très détaillées qui sont données, voici d'ailleurs en exemple une capture d'écran.

Comme vous pouvez le voir ci-dessus, FxCop propose une solution permettant de corriger le problème, et aussi un lien pointant vers une page décrivant plus précisément l'anomalie détectée, j'ai constaté qu'il arrive cependant que la page en question ne soit pas encore disponible, mais cela ne se produit pas dans la majorité des cas. La solution proposée prend en compte la spécificité de votre code. Des informations complémentaires sont également données, il est donc généralement facile de cerner l'anomalie qui a été repérée.

Les anomalies sont classées dans quatre catégories différentes :

• Warning ;
• Critical Warning ;
• Error ;
• Critical Error.

Elles seront placées dans une de ces catégories en fonction de leur degré de gravité, leur nature et les conséquences qu'elles peuvent engendrer en cas de non-correction.

Après avoir étudié les principes de fonctionnement de FxCop, voyons maintenant comment procéder à l'analyse concrète d'assemblies. La première étape consiste à créer un nouveau projet d'analyse, pour cela il faut aller dans le menu « File » et choisir « New project ». Ensuite, il faut sélectionner la, ou les assemblies à analyser, menu « Project », « Add targets ». FxCop charge alors le code à analyser. Voici une capture d'écran montrant à quoi doit ressembler le logiciel à cet instant.

Maintenant nous allons choisir les règles et bonnes pratiques que nous souhaitons vérifier avec FxCop. Cela se passe dans l'onglet « Rules », dans la partie gauche de l'interface. Les règles sont divisées en neuf catégories qui sont les suivantes :

• Design rules ;
• Globalization rules ;
• Interoperability Rules ;
• Mobility Rules ;
• Naming Rules ;
• Performance Rules ;
• Portability Rules ;
• Security Rules ;
• Usage Rules.

Voyons rapidement à quoi correspondent ces catégories.

Design rules : cette catégorie regroupe, comme son nom l'indique, les règles de design .Net. C'est-à-dire les manières de concevoir et de réaliser les différents objets, classes, membres… Cela reprend le contenu du « .NET Framework Design Guidelines » publié par Microsoft.

Globalization Rules : ce sont des règles avec l'application de la globalisation du code et des applications. En relation notamment avec la culture, la langue et les paramètres propres à une région.

Interoperability Rules : ce sont les règles qui vérifient les éléments du code relatif aux problèmes d'interaction avec les clients COM.

Mobility Rules : ces règles vont vérifier qu'il n'y a pas de risque d'activité excessive de l'application, entrainant une surconsommation électrique, par exemple des timers produisant une activité importante et continue, ou qu'une priorité de processus trop grande est donnée à l'application.

Naming Rules : ce sont les règles chargées de vérifier le respect des conventions de nommage des différents éléments dans le code. Elles reprennent les conventions édictées dans le « .NET Framework Design Guidelines. »

Performance Rules : règles vérifiant que le code est conçu de manière à ne pas avoir un impact potentiellement néfaste sur les performances de l'application.

Portability Rules : règles vérifiant la portabilité possible du code vers différentes plateformes.

Security Rules : règles vérifiant qu'il n'y a pas de problème majeur de sécurité au niveau de la conception du code.

Usage Rules : règles vérifiant que les usages dans le développement d'applications .Net sont respectés. Cela couvre des domaines relativement différents.

FxCop propose plus de 200 règles permettant de vérifier de nombreux points précis dans un code donné. Même si ces règles couvrent un champ large, nous allons voir qu'il est cependant possible de créer ses propres règles, et d'ajouter de nouveaux points de contrôle.

FxCop offre la possibilité d'ajouter de nouvelles règles à valider, étendant ainsi quasiment sans limites les vérifications et validations à effectuer sur un code. Dès lors, il devient possible d'ajouter des règles totalement personnalisées, et, collant au plus près aux spécifications et contraintes d'une application. Voilà comment procéder.

Tout d'abord, il faut préciser que les règles sont contenues dans des dll .Net. Il nous faudra donc générer une nouvelle dll pour étendre le nombre de règles prises en charge par FxCop.

Nous allons utiliser Visual Studio 2005 et le langage Visual Basic .Net pour créer une nouvelle règle, mais sachez que n'importe quel IDE ou même Notepad fera l'affaire, il s'agît juste de créer une dll .Net. Il faut donc choisir le type de projet « Bibliothèque de classe ».

Sans plus tarder, il faut ajouter deux références à votre projet. Les références à ajouter concernent deux dll fournies avec FxCop, il s'agit de FxCopSdk.dll et Microsoft.Cci.dll qui se trouvent dans le répertoire d'installation de FxCop, par défaut « C:\Program Files\Microsoft FxCop 1.35 »

Le principe est relativement simple, nous allons créer une classe BaseCustomRule qui dérive d'une classe du SDK, la classe BaseIntrospectionRule. Cette nouvelle classe nous servira de classe de base pour les règles que nous voulons ajouter. Cette classe que nous allons créer devra se trouver dans un namespace DeveloppezCustomRules, qui englobera par ailleurs l'ensemble des classes de notre projet. Nous allons aussi ajouter un constructeur qui permet de passer le nom de la règle concernée, une référence au fichier XML, ainsi qu'à l'assembly. Voilà à quoi doit ressembler votre classe de base.

Imports System
Imports System.Collections.Generic
Imports System.Text
Imports Microsoft.FxCop.Sdk
Imports Microsoft.FxCop.Sdk.Introspection

Namespace DeveloppezCustomRules

    <CLSCompliant(False)> _
    Public MustInherit Class BaseCustomRule
        Inherits BaseIntrospectionRule

        Public Sub New(ByVal ruleName As String)
            MyBase.New(ruleName, "DeveloppezCustomRules.Rules", GetType(BaseCustomRule).Assembly)
        End Sub

    End Class

End Namespace

Une fois cette classe de base créée, nous pouvons édicter nos règles personnalisées. Il va s'agir de classes dérivant de la classe de base. La première classe que je vais ajouter au projet se nomme DeveloppezRule1. Elle comporte les éléments suivants.

• Un constructeur : il prend en paramètre le nom de la règle tel qu'il sera défini dans le fichier XML que nous allons voir plus loin.
• Une méthode BeforeAnalysis() qui se substitue à celle de la classe BaseIntrospectionRule. Cette méthode contient le code qui sera exécuté avant de lancer l'analyse de l'assembly, c'est donc le bon endroit, par exemple, pour initialiser des variables ou effectuer je ne sais quelle action qui vous sera utile.
• Une méthode Check(), elle substitue à la méthode Check de la classe BaseIntrospectionRule. Cette méthode est la plus importante, c'est elle qui contient le code de l'analyse à proprement parler. Cette fonction retourne une ProblemCollection, qui contiendra comme son nom l'indique, le ou les problèmes rencontrés.
• Une méthode AfterAnalysis() qui se substitue à celle de la classe BaseIntrospectionRule. Cette méthode contient le code qui sera exécuté après la vérification de l'assembly par la méthode Check. Dans cette méthode vous pouvez envisager de libérer les ressources utilisées, ou encore, effectuer une quelconque action postvérification en relation avec votre règle personnalisée.

Cette classe contenant notre règle personnalisée, doit bien évidemment faire partie du namespace DeveloppezCustomRules. Voici à quoi pourrait ressembler votre classe :

Imports Microsoft.Cci
Imports Microsoft.FxCop.Sdk
Imports Microsoft.FxCop.Sdk.Introspection


Namespace DeveloppezCustomRules

    <CLSCompliant(False)> _
    Public Class DeveloppezRule1
        Inherits BaseCustomRule


        Public Sub New()
            MyBase.New("DeveloppezRule1")
        End Sub


        Public Overrides Sub BeforeAnalysis()
            ' Code exécuté avant la vérification par Check()

        End Sub


        Public Overrides Function Check(ByVal aMember As Microsoft.Cci.Member) As ProblemCollection

            If aMember Is Nothing Then
                Return Nothing
            End If

            If aMember.Name.ToString.StartsWith("FxCop") Then
                Problems.Add(New Problem(GetResolution(aMember.Name.ToString)))
            End If

            Return Problems

        End Function


        Public Overrides Sub AfterAnalysis()
            ' Code exécuté après la vérification par Check()

        End Sub

    End Class

End Namespace

À la lecture de ces quelques lignes de code je dois vous apporter quelques précisions, notamment à propos de la méthode check. Cette méthode propose six surcharges et donc peut prendre des types de paramètres différents. En voici la liste :

• namespaceName As String, type As Microsoft.Cci.TypeNodeLists ;
• module As Microsoft.Cci.Module ;
• resource As Microsoft.Cci.Resource ;
• type As Microsoft.Cci.TypeNode ;
• member As Microsoft.Cci.Member ;
• parameter As Microsoft.Cci.Parameter.

Ici, elle prend en paramètre un membre de type Microsoft.Cci.Member, c'est le cas puisque notre règle va porter sur l'analyse des membres d'une classe. Son code, que j'ai recopié ci-dessous, nous montre que la vérification va porter le nom des membres de l'assembly, et la condition de « validation » va être que ce nom ne commence pas par « FxCop ». Si jamais c'est le cas, alors on retourne le problème dans une ProblemCollection en utilisant la méthode Add, qui en paramètre prend un objet Problem. Cet objet Problem va lui, prendre en paramètre, la « solution », en effet nous allons pouvoir ici passer une liste de chaînes que l'on pourra retourner à l'utilisateur dans le rapport d'analyse. Vous comprendrez plus tard à quel point ce détail est pratique. Ici, je me contente de retourner le nom de la méthode ; cela me permettra de l'afficher dans le détail du problème que FxCop aura détecté par le biais de notre règle personnalisée. Je me contente de retourner seulement le nom du membre concerné par le problème, mais je peux potentiellement faire passer n'importe quelle information, du moment qu'elle est de type System.String.

        Public Overrides Function Check(ByVal aMember As Microsoft.Cci.Member) As ProblemCollection

            If aMember Is Nothing Then
                Return Nothing
            End If

            If aMember.Name.ToString.StartsWith("FxCop") Then
                Problems.Add(New Problem(GetResolution(aMember.Name.ToString)))
            End If

            Return Problems

        End Function

Nous voyons ici que nous utilisons des tests relativement simples, à base de If / End If, mais, sachez qu'il est possible de faire des choses beaucoup plus complexes, et que l'analyse peut être très poussée, on le constate d'ailleurs avec les règles déjà existantes. Je tiens à attirer votre attention sur l'énumération « Microsoft.cci.NodeType » qui permet de déterminer quel élément il faut cibler dans l'assembly. Cette énumération est très pratique et vous l'utiliserez quasiment à chaque fois.

Nous venons de terminer le code de notre règle personnalisée, cependant il manque une partie importante de la règle, les métadonnées, qui elles, sont contenues dans un fichier XML. Ces informations sont en fait ce qui va permettre à FxCop de donner des indications au développeur analysant ses assemblies. Voici à quoi ressemble le contenu du fichier XML :

<?xml version="1.0" encoding="utf-8" ?>
<Rules FriendlyName="Règles Developpez.com">
  <Rule TypeName="DeveloppezRule1" Category="Microsoft.Naming" CheckId="DVP001">
    <Name>DeveloppezRule1 : noms de membres commençant par "FxCop"</Name>
    <Description>Les noms de membres ne doivent pas commencer par "FxCop"</Description>
    <GroupOwner>Developpez.com</GroupOwner>
    <DevOwner>Webman</DevOwner>
    <Owner>Webman</Owner>
    <Url>http://webman.developpez.com</Url>
    <Resolution>Modifier le nom du membre "{0}" de manière à ce qu'il ne commence pas par "FxCop"</Resolution>
    <Email>mail@mail.com</Email>
    <MessageLevel Certainty="100">Warning</MessageLevel>
    <FixCategories>Breaking</FixCategories>
  </Rule>
</Rules>

Entrons un peu dans le détail.

• TypeName : c'est le nom de la règle, celui que l'on passe au constructeur de la règle personnalisée. Il doit être unique.
• Category : c'est la catégorie de la règle, ici elle correspond à la règle de nommage.
• CheckID : est un identifiant unique de la règle.
• Name : c'est le nom de la règle.
• Description : comme son nom ne l'indique absolument pas… il s'agit de la description de la règle.
• GroupOwner : on spécifie généralement ici le nom de la société.
• Owner : le nom du développeur qui a créé cette règle.
• Url : on spécifie ici une URL pointant vers une aide en ligne correspondant à l'erreur associée à la règle.
• Resolution : c'est le message qui apparait dans le détail de l'anomalie détectée, il propose une solution. C'est dans ce message que l'on peut afficher les informations passées en paramètres à la méthode GetResolution(). Pour afficher ces informations, il suffit de mettre entre accolades {} l'index de la chaine dans la liste de paramètres. Attention, l'index commence à {0} et non à {1} ; de plus si l'on spécifie un index hors tableau une exception sera levée, il faut donc être attentif à ce que l'on fait.
• Email : l'adresse mail du développeur ou de l'entreprise auteur de la règle.
• MessageLevel : l'importance du problème détecté. Cela peut être une des six catégories suivantes : Error, Critical Error, Warning, Critical Warning, Information.
• MessageLevel Certainty : le pourcentage de probabilité que l'anomalie détectée en est réellement une, généralement on utilise un chiffre entre 1 et 99 %, mais l'on peut également utiliser 100 % si on le souhaite.
• FixCategories : la valeur peut être Breaking, NonBreaking ou Unknown, cela signifie respectivement que si l'on applique la solution proposée, il faudra aussi recompiler les assemblies ayant des dépendances avec l'assembly comportant l'anomalie, sous peine d'être confronté à des erreurs d'exécution.
• FriendlyName : ce nom ne concerne pas une règle en particulier, mais l'ensemble des règles contenues dans la dll, ce nom s'affiche dans l'interface de FxCop, dans la liste des dll des règles chargées.

À ce stade, vous n'avez plus qu'à générer votre projet. La dll est alors créée, il vous faut aller dans FxCop, puis dans le menu « Project », « Add Rules » et sélectionner la dll fraichement générée. Vos nouvelles règles apparaissent alors dans la liste, et vous pouvez activer ou non vos règles en globalité, ou alors règle par règle.

Pour que vous compreniez mieux le processus de création de règles personnalisées, voici, deux autres règles personnalisées, comme pour la première, elles se trouvent dans le même namespace, et dérivent de la classe de base que nous avons créée au début de cet article.

La règle suivante a pour but de vérifier que les noms de namespaces contenus dans l'assembly commencent bien par « Dvp ». Voici la classe DeveloppezRule2 :

Imports Microsoft.Cci
Imports Microsoft.FxCop.Sdk
Imports Microsoft.FxCop.Sdk.Introspection


Namespace DeveloppezCustomRules

    <CLSCompliant(False)> _
    Public Class DeveloppezRule2
        Inherits BaseCustomRule


        Public Sub New()
            MyBase.New("DeveloppezRule2")
        End Sub


        Public Overrides Sub BeforeAnalysis()
            ' Code exécuté avant la vérification par Check()
        End Sub


        ' Détecte que le Namespace commence bien par "Dvp"
        Public Overrides Function Check(ByVal namespaceName As String, ByVal types As Microsoft.Cci.TypeNodeList) _ 
                         As ProblemCollection

            If Not namespaceName.StartsWith("Dvp") Then
                Problems.Add(New Problem(GetResolution(namespaceName, namespaceName.Substring(0, 3))))
            End If

            Return Problems

        End Function



        Public Overrides Sub AfterAnalysis()
            ' Code exécuté après la vérification par Check()
        End Sub

    End Class

End Namespace

La troisième règle personnalisée de ce tutoriel, vérifie que le nom des Public Sub(), n'étant pas des événements, est composé d'au mois 7 caractères. Voici le code de la classe DeveloppezRule3 :

Imports Microsoft.Cci
Imports Microsoft.FxCop.Sdk
Imports Microsoft.FxCop.Sdk.Introspection



Namespace DeveloppezCustomRules

    <CLSCompliant(False)> _
    Public Class DeveloppezRule3
        Inherits BaseCustomRule


        Public Sub New()
            MyBase.New("DeveloppezRule3")
        End Sub

        Public Overrides Sub BeforeAnalysis()
            ' Code exécuté avant la vérification

        End Sub

        ' Détecte que le Namespace commence bien par "Dvp"
        Public Overrides Function Check(ByVal member As Microsoft.Cci.Member) As ProblemCollection

            If member.Name Is Nothing Then
                Return Nothing
            End If

            If member.IsPublic And NodeType.Sub And Not NodeType.Event And member.Name.ToString.Length < 7 Then
                Problems.Add(New Problem(GetResolution(member.Name.ToString)))
            End If

            Return Problems

        End Function

        Public Overrides Sub AfterAnalysis()
            ' Code exécuté après la vérification

        End Sub

    End Class

End Namespace

Et enfin, pour que cela soit complet, voici le fichier XML contenant les trois règles personnalisées. Vous remarquerez que les TypeName et CheckID sont uniques au sein du fichier XML, cela est obligatoire.

<?xml version="1.0" encoding="utf-8" ?>
<Rules FriendlyName="Règles Developpez.com">
  <Rule TypeName="DeveloppezRule1" Category="Microsoft.Naming" CheckId="DVP001">
    <Name>DeveloppezRule1 : noms de membres commençant par "FxCop"</Name>
    <Description>Les noms de membres ne doivent pas commencer par "FxCop"</Description>
    <GroupOwner>Developpez.com</GroupOwner>
    <DevOwner>Webman</DevOwner>
    <Owner>Webman</Owner>
    <Url>http://webman.developpez.com</Url>
    <Resolution>Modifier le nom du membre "{0}" de manière à ce qu'il ne commence pas par "FxCop"</Resolution>
    <Email>mail@mail.com</Email>
    <MessageLevel Certainty="100">Warning</MessageLevel>
    <FixCategories>Breaking</FixCategories>
  </Rule>
  
  <Rule TypeName="DeveloppezRule2" Category="Microsoft.Naming" CheckId="DVP002">
    <Name>DeveloppezRule2 : nom de namespace ne commançant pas par "Dvp"</Name>
    <Description>Les noms de namespace doivent commencer par "Dvp"</Description>
    <GroupOwner>Developpez.com</GroupOwner>
    <DevOwner>Webman</DevOwner>
    <Owner>Webman</Owner>
    <Url>http://webman.developpez.com</Url>
    <Resolution>
        Modifier le namespace "{0}" de manière à ce qu'il commence par "Dvp", actuellement il commence par "{1}".
    </Resolution>
    <Email>mail@mail.com</Email>
    <MessageLevel Certainty="100">Error</MessageLevel>
    <FixCategories>Breaking</FixCategories>
  </Rule>

  <Rule TypeName="DeveloppezRule3" Category="Microsoft.Naming" CheckId="DVP003">
    <Name>DeveloppezRule3 : nom de Public Sub() trop court</Name>
    <Description>Les noms de Public Sub() doivent contenir au moins 7 caractères.</Description>
    <GroupOwner>Developpez.com</GroupOwner>
    <DevOwner>Webman</DevOwner>
    <Owner>Webman</Owner>
    <Url>http://webman.developpez.com</Url>
    <Resolution>
        Modifier le Public Sub() "{0}" de manière à ce que son nom contienne au moins 7 caractères.
    </Resolution>
    <Email>mail@mail.com</Email>
    <MessageLevel Certainty="100">Warning</MessageLevel>
    <FixCategories>Breaking</FixCategories>
  </Rule>
  
</Rules>

J'espère qu'au travers de cette partie vous aurez vu à quel point créer des règles personnalisées est chose aisée, et peut être pratique. Je me suis borné ici à donner des exemples relativement simples, pour ne pas masquer l'objectif de cette démonstration, mais, sachez que l'on peut faire des analyses de code très poussées et complexes.

FxCop est un outil autonome, et indépendant de Visual Studio 2005 (sauf dans les versions Team System et Team Suite pour lesquelles il est directement intégré dans l'IDE) mais il pourrait être intéressant de l'intégrer en tant « qu'outil externe ». Cela est tout à fait réalisable, voici comment procéder.

• Allez dans menu « Outils », « Outils externes », bouton « Ajouter ».
• Dans le titre, entrez par exemple « FxCop 1.35 ».
• Dans commande : entrez le chemin pointant vers l'exécutable « FxCopCmd.exe » qui se trouve dans le répertoire d'installation de FxCop, sur ma machine, le chemin complet est « C:\Program Files\Microsoft FxCop 1.35\FxCopCmd.exe ».
• Dans arguments : entrez la ligne suivante, adaptée si besoin au chemin du répertoire « Rules » si le vôtre est différent. « /f:$(TargetPath) /r: »C:\Program Files\Microsoft FxCop 1.35\Rules« /c ».
• Dans répertoire initial, entrez « $(ProjectDir) ».
• Cochez « Utiliser la fenêtre de sortie », ainsi le résultat de l'analyse s'affichera dans cette même fenêtre.

Voici à quoi devrait ressembler la fenêtre de configuration des outils externes :

Maintenant vous devez fermer et rouvrir Visual Studio 2005. L'avantage ici, est que FxCop est directement intégré dans l'IDE, et accessible depuis le menu « Outil », mais personnellement je n'aime pas cette intégration, car afficher le rapport dans la fenêtre de sortie n'est pas très exploitable… En tout cas, bien loin de l'ergonomie de l'interface de FxCop. C'est donc pratique de pouvoir accéder à FxCop de cette manière, mais cela ne dispensera pas d'utiliser FxCop en tant qu'application indépendante.

Au cours de cet article, nous avons vu que FxCop est un outil d'analyse de code très complet, possédant plus de 200 règles, ce qui couvre un domaine vaste. Si vous suivez les recommandations, vous êtes à peu près certain d'avoir un code conforme aux bonnes pratiques .Net, et vous éviterez les problèmes de sécurité majeurs. Mais, un tel outil ne pouvant pas être exhaustif, nous avons vu en contrepartie qu'il est relativement aisé de créer ses propres règles personnalisées d'analyse grâce à un SDK, qui présente malheureusement l'énorme inconvénient de ne pas être documenté, espérons que ce point évoluera rapidement. En effet, ces fonctionnalités sont très intéressantes et méritent que l'on s'y intéresse. J'espère, au travers de cet article, avoir réussi à vous montrer l'utilité réelle, et le gain de productivité que peut vous apporter FxCop, et que désormais, cet outil fera partie des applications que vous utiliserez au quotidien.

Un grand merci à Khany pour la relecture de cet article, ainsi qu'à l'équipe .Net pour son aide.