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

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

/ warnaserror / warnaserror-: 618

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

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.

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.

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

avviso pragma (riferimenti per C #) pragma warning (C # Reference)

pragma warning può essere utilizzato per abilitare o disabilitare determinati avvisi.

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

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.