Intégration Continue avec Visual Studio et Team Foundation Server - Partie I, Présentation de MsTest et de Static Code Analysis

Cependant certains éléments du code ne sont pas liés à un emplacement (fichier) fixe. C'est typiquement le cas d'un namespace. Par conséquent, il ne serait pas judicieux d'ajouter un attribut « SuppressMessageAttribute » dans un fichier plutôt que dans un autre.

Visual Studio nous offre la possibilité de créer un fichier global qui peut contenir une liste de suppressions d'erreurs. Notez que ce n'est que depuis la version 2008 que Visual Studio nous laisse le choix du positionnement des erreurs que l'on supprime.

Ce fichier – nommé « GlobalSuppressions.cs » ou « GlobalSuppressions.vb » se trouve à la racine du projet concerné et va contenir par exemple les lignes suivantes :

[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Naming", 
           "CA1705:LongAcronymsShouldBePascalCased", 
           Scope = "namespace", 
           Target = "MyRootNamespace")]
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Performance", 
           "CA1805:DoNotInitializeUnnecessarily", 
           Scope = "member", 
           Target = "MyRootNamespace.MyClass..ctor()")]
[assembly: System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Usage", 
           "CA2215:DisposeMethodsShouldCallBaseClassDispose", 
           Scope = "member", 
           Target = "MyRootNamespace.MyClass.Dispose(System.Boolean):System.Void")]

On retrouve la même syntaxe que dans les attributs « traditionnels », mais on retrouve deux paramètres nommés supplémentaires : « Scope » et « Target ».

Scope nous permet de préciser le type d'objet que l'on cible. En pratique seuls namespace et member seront utilisés.

Target quant à lui spécifie l'objet pour lequel on veut supprimer l'erreur. On doit toujours préciser le nom complet, namespace inclus.

Notez que pour une méthode, on doit utiliser la syntaxe « Type.NomMethode([TypeParamètre1[, TypeParametre2[…]]]):TypeRetour » ou chaque « Type » correspond en fait a son FullName, soit « Namespace[.ChildNamespace[…]].Type ».

Certaines méthodes du framework ont des noms réservés lors de la compilation en code IL. Pour connaître ces différents noms, il « suffit » de connaître le code qui est généré par le compilateur. ILDASM ou Reflector.NET pourra donc vous montrer le nom correct de votre méthode.

Pour citer quelques exemples, on pourra noter :

public class Class1
{
   public Class1() { }
}

public class Class1
{
   static Class1() { }
}

public class Class1
{
   ~Class1() { }
}

public class Class1
{
   public static implicit operator Class1(string b) {}
   public static explicit operator Class1(double b) {}
   public static Class1 operator +(Class1 a, Class1 b) {}
   public static Class1 operator -(Class1 a, Class1 b) {}
   public static Class1 operator /(Class1 a, Class1 b) {}
   public static Class1 operator *(Class1 a, Class1 b) {}
   public static Class1 operator ==(Class1 a, Class1 b) {}
   public static Class1 operator !=(Class1 a, Class1 b) {}
   public static Class1 operator <(Class1 a, Class1 b) {}
   public static Class1 operator >(Class1 a, Class1 b) {}
   public static Class1 operator <=(Class1 a, Class1 b) {}
   public static Class1 operator >=(Class1 a, Class1 b) {}
   public static Class1 operator <<(Class1 a, int i) {}
}

Si vous désirez utiliser un autre nom de fichier, vous pouvez éditer le fichier de projet (.csproj / .vbproj) et ajouter la ligne suivante (où [name] est le nouveau nom du fichier - sans chemin):

<PropertyGroup>
    <CodeAnalysisModuleSuppressionsFile>[name]</CodeAnalysisModuleSuppressionsFile>
</PropertyGroup>