"Considera tutti gli avvisi come errori tranne ..." in Visual Studio


124

In Visual Studio, posso selezionare l'opzione "Considera gli avvisi come errori" per impedire la compilazione del codice in caso di avvisi. Il nostro team utilizza questa opzione, ma ci sono due avvisi che vorremmo mantenere come avvisi.

C'è un'opzione per sopprimere gli avvisi, ma vogliamo che vengano visualizzati come avvisi, quindi non funzionerà.

Sembra che l'unico modo per ottenere il comportamento desiderato è inserire un elenco di ogni numero di avviso C # nella casella di testo "Avvisi specifici", ad eccezione dei due che vogliamo vengano trattati come avvisi.

Oltre al problema di manutenzione, il più grande svantaggio di questo approccio è che alcuni avvisi non hanno numeri, quindi non è possibile fare riferimento esplicitamente. Ad esempio, "Impossibile risolvere questo riferimento. Impossibile individuare l'assembly" Dati .... ""

Qualcuno sa di un modo migliore per farlo?


Chiarire per chi non vede subito perché è utile. Pensa a come funzionano la maggior parte degli avvisi. Ti dicono che c'è qualcosa di strano nel codice che hai appena scritto. Occorrono circa 10 secondi per risolverli e ciò mantiene la base del codice più pulita.

L'avviso "Obsoleto" è molto diverso da questo. A volte risolverlo significa semplicemente consumare una nuova firma del metodo. Ma se un'intera classe è obsoleta e la si utilizza sparsi per centinaia di migliaia di righe di codice, potrebbero essere necessarie settimane o più per la correzione. Non vuoi che la build venga interrotta per così tanto tempo, ma sicuramente vuoi vedere un avvertimento al riguardo. Questo non è solo un caso ipotetico, è successo a noi.

Anche gli avvisi letterali "#warning" sono unici. Spesso desidero archiviarlo, ma non voglio interrompere la build.


Puoi per favore mettere degli spazi nel tuo grande elenco di numeri? Ha riempito la linea di avvolgimento.
Ray

Odio, odio le regole complicate inventate dalle persone, spesso per lenire l'ego di una persona specifica.
Jon Limjap

21
Capisco il suo punto sull'avvertimento obsoleto, questo non è arbitrario.
Ed S.

Nella mia esperienza, consentire anche un solo avviso nella build è come aggiungere un primo async / await. Presto ce ne saranno decine. In tutte le configurazioni ricordo che uno sviluppatore è in grado di vedere meno di 10 avvisi nella finestra Elenco errori in VS. Posso scommettere che non appena avrai più di 5 avvisi la stragrande maggioranza degli sviluppatori in una squadra non sarà in grado di individuarne uno nuovo - nella tua configurazione significa che non individueranno l'avviso che il metodo è obsoleto, il che sfida lo scopo di averlo un avvertimento :) Qual è la tua esperienza con questo Neil?
tymtam

@ mayu, è un enigma. Molte volte ho visto che gli avvisi sono stati ignorati per molto tempo. Ma alla fine, o mostri l'avvertimento o non mostri nulla. Se stai mostrando l'avvertimento, almeno c'è la possibilità che qualcuno impari qualcosa di utile da esso. Se tratti la maggior parte degli avvisi come errori, i pochi rimasti possono ricevere maggiore attenzione.
Neil

Risposte:


155

Puoi aggiungere un WarningsNotAsErrorstag nel file di progetto.

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

Nota: 612e 618sono entrambi avvertimenti su Obsoleto, non so la differenza ma il progetto su cui sto lavorando segnala Obsolete con avvertimento 618.


24
La differenza tra 612 e 618 è il commento di ObsoleteAttribute. Un attributo obsoleto senza commento genera l'errore 612 e uno con un commento genera 618.
Marco Spatz

@MarcoSpatz Esattamente. Poi possiamo trattare [Obsolete]i membri dove il messageè nullcome errori, mentre lasciamo quelli in cui il messageè impostato solo rimanere avvertimenti. Se il errorparametro è impostato su truein ObsoleteAttribute, viene invece generato un CS0619. Questo sembra non funzionare se lo messageè null(ma chi lo farebbe [Obsolete(null, true)]comunque?).
Jeppe Stig Nielsen

Per F #, utilizzare --warnaserror-:618,1030nel campo Build-> Other flags. Questa opzione di progetto non è ancora implementata per i progetti F #. github.com/Microsoft/visualfsharp/issues/3395
Asik

2
Buono a sapersi "WarningsNotAsErrors" esiste. Dovrebbe essere disponibile nelle impostazioni del progetto senza modificare manualmente il file. Grazie.
AFract

1
Microsoft ha davvero sbagliato tutto (e 11 anni dopo, non ha risolto le cose!). Le impostazioni del progetto cambiano <NoWarn>, il che è inferiore nella maggior parte dei casi e non è stato possibile inserire <WarningsNotAsErrors>nell'interfaccia utente. Complimenti.
user2864740

13

/ warnaserror / warnaserror-: 618


1
Grazie per il tuo contributo. Anche se non risolvono il problema IDE, questi sono i commenti più utili finora.
Neil

2
Dove lo aggiungi?
checho

@checho, queste opzioni verranno aggiunte alla riga di comando quando si chiama msbuild. Per i nostri scopi, la risposta principale è più utile, perché possiamo inserirla nel progetto invece di dover modificare il modo in cui chiamiamo msbuild.
Neil

Non funziona con MSBuild 15.9.21 + g9802d43bc3: MSBUILD : error MSB1001: Unknown switch. Switch: /warnaserror-:618
Paul B.

3

o più specificamente, nel tuo caso:

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

questo dovrebbe considerare tutti gli avvisi come errori tranne quelli nell'elenco separato da virgole


1

Perché desideri continuare a visualizzare avvisi che non stai trattando come errori? Sono confuso sul motivo per cui questo è desiderabile: o li aggiusti o non lo fai.

Funzionerebbero due diversi file di build / soluzione o uno script per copiarne uno e quindi modificare il livello di avvertenza / avvertenza. Sembra che forse tu voglia che alcune esecuzioni del compilatore squawk, ma altre che vuoi andare avanti.

Quindi diverse opzioni del compilatore sembrano un buon modo per andare. Puoi farlo con diversi obiettivi: uno etichettato come debug o rilascio e gli altri etichettati adeguatamente sugli avvisi.


7
La maggior parte degli avvisi avviene a causa di una semplice confusione nel mio codice (ad esempio, ho dichiarato una variabile che non uso). Un avviso Obsoleto si verifica spesso a causa di una modifica nel codice di qualcun altro. La risoluzione di questo problema potrebbe richiedere settimane di sviluppo. #warning è un avviso che voglio nel codice (probabilmente una soluzione a lungo termine).
Neil

4
In altre parole, ci sono avvertimenti che non voglio interrompere la mia build. Se #warning interrompe la build, non posso mai registrarne una. Se Obsolete interrompe la build, un altro team da cui dipendiamo potrebbe inconsapevolmente rompere la build del nostro team semplicemente aggiungendo un attributo obsoleto.
Neil

@Neil Sono d'accordo con alcuni dei tuoi argomenti, ma rimuovere una var che non usi non richiede molto tempo E vuoi sicuramente sapere che un altro team ha reso qualcosa di obsoleto.
tymtam

@mayu, grazie per il tuo commento. Sono d'accordo su una var che non usi. Ecco perché vorrei che il compilatore lo considerasse un errore. Sono anche d'accordo che vuoi sapere quando qualcosa è obsoleto. Ma se ci vuole un tempo proibitivo per effettuare il refactoring di qualcosa di obsoleto del tuo codice, le tue scelte sono 1) Tratta questo avviso come un avvertimento 2) Lascia che la tua build rimanga rotta per molto tempo 3) Qualche altra soluzione come disattivare gli avvisi come errori. Con la maggior parte degli avvisi come errori, è probabile che il tuo elenco di avvisi rimanga breve, quindi è più probabile che tu lo noti quando vengono visualizzati. Qual è la tua soluzione preferita?
Neil

1
@mayu, un altro team (all'interno della stessa azienda o al di fuori di essa) potrebbe legittimamente voler comunicare che una classe, un metodo, un altro componente è stato gradualmente eliminato per un certo periodo di tempo. L'aggiunta di un attributo è un buon modo per segnalarlo ai consumatori di una libreria. Non vedo come problematico farlo. In effetti, l'aggiunta dell'attributo il prima possibile è un buon modo per assicurarsi che gli altri siano consapevoli dei cambiamenti futuri.
Neil

1

Sto usando considera gli avvisi come errori.

In rari casi, quando viene visualizzato un avviso accettabile (ad es. Riferimento a un membro obsoleto o documentazione mancante sulle classi di serializzazione XML), è necessario eliminarlo esplicitamente con #pragma disable (e facoltativamente potrebbe essere fornito un motivo per non avere un codice pulito come commento lungo).

La presenza di questa direttiva permette anche di scoprire chi ha accettato questa violazione di avvertimento (per azione di "colpa" del controllo di versione) in caso di domande.


3
Uso anche questo, sebbene non risolva i problemi menzionati nella mia descrizione. Desidero che determinati avvisi vengano trattati come avvisi, non nascosti.
Neil

0

Perché non avere semplicemente una regola che dice "Chiunque controlli il codice con all'interno un avviso diverso da 612, 1030, 1701 o 1702 deve andare sulla lavagna e scrivere cento volte" Non controllerò più il codice con avvisi non consentiti. '"


9
Buona fortuna a farlo ... Trattare gli avvisi come errori è un passo molto importante per aumentare la qualità generale del codice e costringerà gli sviluppatori a correggere effettivamente il loro codice! Tutta l'automazione della grandine, il lavoro manuale è così del XX secolo: ish!
Andreas Magnusson

@AndreasMagnusson Se solo la mancanza di avvertenze garantisse effettivamente la qualità del codice ..
user2864740

2
@ user2864740: D'accordo, non ci sono proiettili d'argento. Ma è un errore fin troppo comune rifiutare qualcosa di utile partendo dal presupposto che non è un proiettile d'argento.
Andreas Magnusson


-4

Mi sembra che il problema principale sia in realtà una combinazione del tuo trattamento degli avvertimenti come errori, quando chiaramente non lo sono, e della tua apparente politica di consentire i check-in che violano questo. Come dici tu, vuoi essere in grado di continuare a lavorare nonostante un avvertimento. Hai menzionato solo alcuni avvisi che desideri ignorare, ma cosa succederebbe se qualcun altro del team causasse un altro tipo di avviso, che richiederebbe altrettanto tempo per essere risolto? Non vorresti essere in grado di ignorare anche questo?

La soluzione logica sarebbe 1) non consentire i check-in se il codice non viene compilato (il che significa che coloro che hanno creato gli avvisi dovranno risolverli, poiché in effetti hanno interrotto la compilazione) o 2) trattare gli avvisi come avvisi. Crea due configurazioni di build, una che tratta gli avvisi come errori, che può essere eseguita regolarmente per garantire che il codice sia privo di avvisi, e un'altra, che li tratta solo come avvisi e ti consente di lavorare anche se qualcun altro ha introdotto un avviso.


1
Utilizzando la risposta selezionata, è facile aggiungerla all'elenco di avvisi trattati come avvisi. Funziona molto meglio di una delle soluzioni proposte. Gli avvisi chiaramente non sono errori, ma trattare la maggior parte degli avvisi come errori significa che il codice non verrà mai controllato con quegli avvisi.
Neil
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.