Analyser du code .Net avec FxCop
Date de publication : 20/11/2006
Par
Ronald VASSEUR (autres articles)
Ecrire du code n'est pas chose difficile, écrire du code dans "les règles de
l'art" l'est déjà plus ! Un outil gratuit, et spécialisé dans l'analyse du code .Net,
vous offre la possibilité de vérifier qu'il n'y a pas d'anomalie, ou même d'erreur grave,
dans vos assemblies, et que celles-ci sont conformes aux "bonnes pratiques" recommandées par Microsoft.
Cet outil se nomme FxCop, il fonctionne aussi bien avec les
assemblies .Net 1.1 que 2.0, je vais essayer au cours de cet article de vous montrer
l'avantage que vous pouvez tirer d'une telle application.
Introduction
1. Installer
2. Présentation
3. Analyser ses assemblies
4. Ajouter de nouvelles règles personnalisées
5. Intégrer FxCop dans Visual Studio 2005
Ressources
Conclusion
Introduction
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 impose 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éfinit, 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,
voir même 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étails FxCop,
voyons tout d'abord où trouver ce logiciel, et comment l'installer.
1. 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.
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 :
 |
Remarque : petite précision, FxCop fonctionnera quelque soit l'environnement
de développement que vous utilisez ! Cela va donc de Notepad à Visual
Studio 2005 Team Suite, en passant par SharpDevelop. En effet, FxCop
est totalement indépendant de ces logiciels, et fonctionne de manière
autonome.
|
2. Présentation
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'agisse 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.
Liste des anomalies détectées
Détails d'une anomalie
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.
|
Remarque : il faut préciser que, s'il est possible d'analyser plusieurs
assemblies en même temps, celles-ci doivent utiliser la même version
du Framework. Par exemple, analyser une assembly .Net 1.1 et une 2.0
en même temps ne sera pas possible.
|
3. Analyser ses assemblies
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, comme par exemple des timers produisant une activité
importante et continue, ou qu'une priorité de processus trop grande
soit 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ôles.
4. Ajouter de nouvelles règles personnalisées
FxCop offre la possibilité d'ajouter de nouvelle règles à valider,
étendant ainsi quasiment sans limite 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 prisent 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'agît
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.
| Classe BaseCustomRule |
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éfinit 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 post-vé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 :
| Classe DeveloppezRule1 |
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()
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()
End Sub
End Class
End Namespace |
A 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ètres 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.
| Fonction Check() |
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 :
| Fichier Rules.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 commencant 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'agît 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 à créer 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 juste de mettre entre accolades {} l'index de la chaine dans la liste de paramètre. Attention, l'index commence à {0} et non à {1} ; de plus s'il 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 soit 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.
 |
Remarque : le fichier XML devra être intégré dans la dll, cela signifie
que "Actions de génération" devra être positionné sur "Ressource
incorporée", et que "Copier dans le répertoire de sortie" devra
être positionné à "Ne pas copier".
|
A 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éé 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 :
| 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()
End Sub
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()
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 :
| 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()
End Sub
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()
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.
| Fichier Rules.xml complet |
<?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 commencant 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 commancant 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ée est chose aisé, 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.
5. Intégrer FxCop dans Visual Studio 2005
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.
- Aller 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 ré-ouvrir 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.
Ressources
Conclusion
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 contre-partie 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érient 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.
Les sources présentées sur cette page sont libres de droits,
et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation
constitue une oeuvre intellectuelle protégée par les droits d'auteurs. Copyright ©
2006 Ronald Vasseur. Aucune reproduction,
même partielle, ne peut être faite de ce site et de l'ensemble de son contenu :
textes, documents, images, etc sans l'autorisation expresse de l'auteur.
Sinon vous encourez selon la loi jusqu'à 3 ans de prison et jusqu'à 300 000 E
de dommages et intérêts. Droits de diffusion permanents accordés à developpez LLC.
Cette page est déposée à la
SACD.
