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


124

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.


Pouvez-vous s'il vous plaît mettre des espaces dans votre grande liste de nombres? Il a bourré l'enroulement de la ligne.
Ray

Gawd Je déteste les règles compliquées qui sont inventées par des gens, souvent pour apaiser l'ego d'une personne en particulier.
Jon Limjap

21
Je vois son point sur l'avertissement obsolète, ce n'est pas arbitraire.
Ed S.

D'après mon expérience, autoriser ne serait-ce qu'un avertissement dans votre build, c'est comme ajouter un premier async / await. Bientôt, il y en aura des dizaines. Dans toutes les configurations, je me souviens qu'un développeur est capable de voir moins de 10 avertissements dans la fenêtre Liste d'erreurs de VS. Je peux parier que dès que vous avez plus de 5 avertissements, la grande majorité des développeurs d'une équipe ne pourront pas en repérer un nouveau - dans votre configuration, cela signifie qu'ils ne repéreront pas l'avertissement que la méthode est obsolète, ce qui défie le but même d'avoir un avertissement :) Quelle est votre expérience avec ce Neil?
tymtam

@mayu, c'est une énigme. Plusieurs fois, j'ai vu des avertissements être ignorés pendant longtemps. Mais à la fin, soit vous montrez l'avertissement, soit vous ne montrez rien du tout. Si vous montrez l'avertissement, au moins il y a une chance que quelqu'un en apprenne quelque chose d'utile. Si vous traitez la plupart des avertissements comme des erreurs, les quelques avertissements qui restent peuvent attirer davantage l'attention.
Neil

Réponses:


155

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.


24
La différence entre 612 et 618 est le commentaire de ObsoleteAttribute. Un ObsoleteAttribute sans commentaire génère l'erreur 612, et un avec un commentaire génère 618.
Marco Spatz

@MarcoSpatz Exactement. Ensuite, nous pouvons traiter les [Obsolete]membres où messageest nullcomme des erreurs, tandis que nous laissons ceux où messageest défini rester des avertissements uniquement. Si le errorparamètre est défini sur truedans ObsoleteAttribute, un CS0619 est généré à la place. Cela semble ne pas fonctionner si messagec'est null(mais qui ferait de [Obsolete(null, true)]toute façon?).
Jeppe Stig Nielsen

Pour F #, utilisez --warnaserror-:618,1030le champ Build-> Other flags. Cette option de projet n'est pas encore implémentée pour les projets F #. github.com/Microsoft/visualfsharp/issues/3395
Asik

2
Bon à savoir "WarningsNotAsErrors" existe. Il doit être disponible dans les paramètres du projet sans modifier manuellement le fichier. Merci.
AFract

1
Microsoft a vraiment foiré cela (et 11 ans plus tard, n'a pas réglé les choses!). Les paramètres du projet changent <NoWarn>, ce qui est inférieur dans la plupart des cas et n'a pas pu être mis <WarningsNotAsErrors>dans l'interface utilisateur. Gloire.
user2864740 le

13

/ warnaserror / warnaserror-: 618


1
Merci pour votre participation. Même s'ils ne résolvent pas le problème de l'IDE, ce sont les commentaires les plus utiles à ce jour.
Neil

2
Où ajoutez-vous cela?
checho

@checho, ces commutateurs seraient ajoutés sur la ligne de commande lors de l'appel de msbuild. Pour nos besoins, la première réponse est plus utile, car nous pouvons l'intégrer au projet au lieu d'avoir à modifier la façon dont nous appelons msbuild.
Neil

Ne fonctionne pas avec MSBuild 15.9.21 + g9802d43bc3: MSBUILD : error MSB1001: Unknown switch. Switch: /warnaserror-:618
Paul B.

3

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


1

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.


7
La plupart des avertissements se produisent à cause d'une simple confusion dans mon code (par exemple, j'ai déclaré une variable que je n'utilise pas). Un avertissement obsolète se produit souvent en raison d'un changement dans le code de quelqu'un d'autre. Résoudre ce problème pourrait prendre des semaines de développement. #warning est un avertissement que je veux dans le code (probablement un correctif à long terme).
Neil

4
En d'autres termes, il y a des avertissements que je ne veux pas casser ma construction. Si #warning rompt la construction, alors je ne peux jamais en enregistrer une. Si Obsolete rompt la construction, alors une autre équipe dont nous dépendons pourrait briser sans le savoir la construction de notre équipe simplement en ajoutant un attribut obsolète.
Neil

@Neil Je suis d'accord avec certains de vos arguments, mais supprimer une var que vous n'utilisez pas ne prend pas beaucoup de temps ET vous voulez vraiment savoir qu'une autre équipe a rendu quelque chose obsolète.
tymtam

@mayu, merci pour votre commentaire. Je suis d'accord sur une var que vous n'utilisez pas. C'est pourquoi je demanderais au compilateur de le traiter comme une erreur. Je conviens également que vous voulez savoir quand quelque chose est obsolète. Mais si cela prend trop de temps pour refactoriser quelque chose d'obsolète de votre code, vos choix sont 1) Traitez cet avertissement comme un avertissement 2) Laissez votre build rester interrompu pendant longtemps 3) Une autre solution comme désactiver les avertissements comme des erreurs. La plupart des avertissements étant des erreurs, votre liste d'avertissements est susceptible de rester courte, vous êtes donc plus susceptible de remarquer quand ils apparaissent. Quelle est votre solution préférée?
Neil

1
@mayu, une autre équipe (que ce soit au sein de la même entreprise ou en dehors de celle-ci) peut légitimement vouloir communiquer qu'une classe, une méthode, un autre composant est en cours de suppression sur une certaine période de temps. L'ajout d'un attribut est un bon moyen de le signaler aux consommateurs d'une bibliothèque. Je ne vois pas cela gênant de faire cela. En fait, ajouter l'attribut le plus tôt possible est un bon moyen de s'assurer que les autres sont conscients des changements futurs.
Neil

1

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.


3
Je l'utilise également, même si cela ne résout pas les problèmes mentionnés dans ma description. Je souhaite que certains avertissements soient traités comme des avertissements et non masqués.
Neil

0

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. '"


9
Bonne chance pour faire respecter cela ... Traiter les avertissements comme des erreurs est une étape très importante pour augmenter la qualité globale du code et cela obligera les développeurs à corriger leur code! Toute automatisation grêle, le travail manuel est tellement du 20e siècle: ish!
Andreas Magnusson

@AndreasMagnusson Si seulement le manque d'avertissements assurait réellement la qualité du code ..
user2864740

2
@ user2864740: D'accord, il n'y a pas de balles d'argent. Mais c'est une erreur trop courante de rejeter quelque chose d'utile en partant du principe que ce n'est pas une solution miracle.
Andreas Magnusson


-4

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.


1
En utilisant la réponse sélectionnée, il est facile d'ajouter à la liste des avertissements traités comme des avertissements. Cela fonctionne beaucoup mieux que l'une ou l'autre de vos solutions proposées. Les avertissements ne sont clairement pas des erreurs, mais traiter la plupart des avertissements comme des erreurs signifie que le code ne sera jamais enregistré avec ces avertissements.
Neil
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.