"Traitez tous les avertissements comme des erreurs sauf…" dans Visual Studio

Dans Visual Studio, je peux sélectionner l'option «Traiter les avertissements comme des erreurs» pour empêcher la compilation de mon code en cas d'avertissement. Notre équipe utilise cette option, mais il y a deux avertissements que nous aimerions garder comme avertissements.

Il existe une option pour supprimer les avertissements, mais nous voulons qu'ils apparaissent comme des avertissements, donc cela ne fonctionnera pas.

Il semble que la seule façon d'obtenir le comportement souhaité est de saisir une liste de chaque numéro d'avertissement C # dans la zone de texte "Avertissements spécifiques", à l'exception des deux que nous voulons traiter comme des avertissements.

Outre le mal de tête lié à la maintenance, le plus gros inconvénient de cette approche est que quelques avertissements n'ont pas de chiffres, ils ne peuvent donc pas être référencés explicitement. Par exemple, "Impossible de résoudre cette référence. Impossible de localiser l'assembly 'Data ....'"

Quelqu'un connaît-il une meilleure façon de faire cela?

Clarifier pour ceux qui ne voient pas immédiatement pourquoi cela est utile. Réfléchissez au fonctionnement de la plupart des avertissements. Ils vous disent que quelque chose ne va pas dans le code que vous venez d'écrire. Cela prend environ 10 secondes pour les réparer, ce qui maintient la base de code plus propre.

L'avertissement "Obsolète" est très différent de celui-ci. Parfois, le réparer signifie simplement consommer une nouvelle signature de méthode. Mais si une classe entière est obsolète et que son utilisation est dispersée sur des centaines de milliers de lignes de code, cela peut prendre des semaines ou plus à réparer. Vous ne voulez pas que la construction soit interrompue aussi longtemps, mais vous voulez certainement voir un avertissement à ce sujet. Ce n'est pas seulement un cas hypothétique - cela nous est arrivé.

Les avertissements "#warning" littéraux sont également uniques. Je veux souvent l' enregistrer, mais je ne veux pas interrompre la compilation.

Vous pouvez ajouter un WarningsNotAsErrors-tag dans le fichier projet.

<PropertyGroup>
    ...
    ...
    <WarningsNotAsErrors>618,1030,1701,1702</WarningsNotAsErrors>
</PropertyGroup>

Remarque: 612et 618sont tous deux des avertissements concernant Obsolète, je ne connais pas la différence, mais le projet sur lequel je travaille indique Obsolète avec l'avertissement 618.

/ warnaserror / warnaserror-: 618

ou plus précisément, dans votre cas:

/ warnaserror / warnaserror-: 612,1030,1701,1702

cela devrait traiter tous les avertissements comme des erreurs à l'exception de ceux de votre liste séparée par des virgules

Pourquoi voulez-vous continuer à voir des avertissements que vous ne traitez pas comme des erreurs? Je ne comprends pas pourquoi c'est souhaitable - soit vous les corrigez, soit vous ne le faites pas.

Est-ce que deux fichiers de construction / solution différents fonctionneraient - ou un script pour en copier un puis modifier le niveau d'avertissement / d'avertissement serait approprié. Il semble que vous souhaitiez peut-être que certaines exécutions du compilateur sifflent, mais d'autres que vous souhaitiez continuer.

Donc, différents commutateurs de compilateur semblent être une bonne solution. Vous pouvez le faire avec différentes cibles - l'une étiquetée debug ou release et les autres étiquetées de manière appropriée sur les avertissements.

J'utilise traiter les avertissements comme des erreurs.

Dans de rares cas, lorsqu'un avertissement acceptable apparaît (c'est-à-dire faisant référence à un membre obsolète ou à une documentation manquante sur les classes de sérialisation XML), il doit être explicitement supprimé avec #pragma disable (et éventuellement une raison pour ne pas avoir de code propre pourrait être fournie en commentaire).

La présence de cette directive permet également de savoir, qui a accepté cette violation d'avertissement (par action "blâme" du contrôle de version) au cas où il y aurait des questions.

Pourquoi ne pas simplement avoir une règle disant "Quiconque enregistre le code avec un avertissement à l'intérieur autre que 612, 1030, 1701 ou 1702 doit aller au tableau blanc et écrire cent fois" Je ne vérifierai plus le code avec des avertissements non autorisés. '"

avertissement pragma (référence C #)

L'avertissement pragma peut être utilisé pour activer ou désactiver certains avertissements.

http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx

Il me semble que le problème fondamental est en réalité une combinaison de votre traitement des avertissements comme des erreurs, alors qu'ils ne le sont clairement pas, et de votre politique apparente consistant à autoriser les enregistrements qui enfreignent cela. Comme vous le dites, vous voulez pouvoir continuer à travailler malgré un avertissement. Vous n'avez mentionné que quelques avertissements que vous voulez pouvoir ignorer, mais que se passerait-il si quelqu'un d'autre dans l'équipe provoquait un autre type d'avertissement, ce qui vous prendrait tout aussi longtemps à corriger? Ne voudriez-vous pas pouvoir ignorer cela également?

La solution logique serait de 1) interdire les vérifications si le code ne se compile pas (ce qui signifie que ceux qui ont créé les avertissements devront les corriger, car en fait, ils ont cassé la construction), ou 2) traiter les avertissements comme des avertissements. Créez deux configurations de construction, une qui traite les avertissements comme des erreurs, qui peuvent être exécutées régulièrement pour garantir que le code est sans avertissement, et une autre, qui ne les traite que comme des avertissements et vous permet de travailler même si quelqu'un d'autre a introduit un avertissement.