"Trate todos os avisos como erros, exceto ..." no Visual Studio

No Visual Studio, posso selecionar a opção "Tratar avisos como erros" para impedir que meu código seja compilado se houver algum aviso. Nossa equipe usa essa opção, mas há dois avisos que gostaríamos de manter como avisos.

Existe uma opção para suprimir avisos, mas queremos que eles apareçam como avisos, para que não funcionem.

Parece que a única maneira de obter o comportamento que queremos é inserir uma lista de todos os números de aviso de C # na caixa de texto "Avisos específicos", exceto os dois que queremos que sejam tratados como avisos.

Além da dor de cabeça na manutenção, a maior desvantagem dessa abordagem é que alguns avisos não possuem números e, portanto, não podem ser referenciados explicitamente. Por exemplo, "Não foi possível resolver esta referência. Não foi possível localizar o conjunto 'Dados ....'"

Alguém sabe de uma maneira melhor de fazer isso?

Esclarecendo para quem não vê imediatamente por que isso é útil. Pense em como a maioria dos avisos funciona. Eles dizem que algo está um pouco errado no código que você acabou de escrever. Demora cerca de 10 segundos para corrigi-los, e isso mantém a base de código mais limpa.

O aviso "Obsoleto" é muito diferente disso. Às vezes, corrigi-lo significa apenas consumir uma nova assinatura de método. Mas se uma classe inteira é obsoleta e você pode usá-la espalhada por centenas de milhares de linhas de código, pode levar semanas ou mais para corrigir. Você não quer que a compilação seja quebrada por tanto tempo, mas definitivamente deseja receber um aviso sobre isso. Este não é apenas um caso hipotético - isso aconteceu conosco.

Os avisos literais de "#warning" também são exclusivos. Muitas vezes, quero fazer check-in, mas não quero interromper a compilação.

Você pode adicionar uma WarningsNotAsErrorsetiqueta no arquivo do projeto.

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

Nota: 612e 618são ambos avisos sobre Obsoleto, não sei a diferença, mas o projeto no qual estou trabalhando está relatando Obsoleto com o aviso 618.

/ warnaserror / warnaserror-: 618

ou, mais especificamente, no seu caso:

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

isso deve tratar todos os avisos como erros, exceto os da lista separada por vírgula

Por que você deseja continuar vendo avisos de que não está tratando como erros? Estou confuso sobre por que isso é desejável - ou você os corrige ou não.

Dois arquivos diferentes de construção / solução funcionariam - ou um script para copiar um e, então, modificar o nível de avisos / avisos seria adequado. Parece que talvez você queira que algumas execuções do compilador gritem, mas outras que você deseja continuar.

Portanto, diferentes opções de compilador parecem um bom caminho a percorrer. Você pode fazer isso com diferentes destinos - um rotulado como debug ou release e os outros rotulados adequadamente sobre os avisos.

Estou usando tratar avisos como erros.

Em casos raros, quando algum aviso aceitável aparece (por exemplo, referenciando membro obsoleto ou documentação ausente nas classes de serialização XML), ele deve ser explicitamente suprimido com a desativação #pragma (e, opcionalmente, pode ser fornecido o motivo para não ter um código limpo como um comentário).

A presença desta diretiva também permite descobrir quem aceitou esta violação de aviso (por ação "culpada" do controle de versão), caso haja algumas perguntas.

Por que simplesmente não ter uma regra dizendo "Quem quer que verifique o código com qualquer aviso que não seja 612, 1030, 1701 ou 1702 nele deve ir para o quadro branco e escrever centenas de vezes 'Não irei verificar o código com avisos não permitidos novamente. '"

aviso pragma (Referência de C #)

o aviso pragma pode ser usado para ativar ou desativar certos avisos.

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

Parece-me que o problema principal é realmente uma combinação de tratar os avisos como erros, quando claramente não o são, e sua aparente política de permitir check-ins que violam isso. Como você diz, deseja continuar trabalhando apesar de um aviso. Você mencionou apenas alguns avisos que deseja poder ignorar, mas e se alguém da equipe causasse outro tipo de aviso, o que levaria um tempo igualmente para ser corrigido? Você não gostaria de poder ignorar isso também?

A solução lógica seria 1) Não permitir check-ins se o código não compilar (o que significa que aqueles que criaram os avisos precisarão corrigi-los, pois, na verdade, eles quebraram a compilação) ou 2) tratam os avisos como avisos. Crie duas configurações de compilação, uma que trate avisos como erros, que podem ser executados regularmente para garantir que o código esteja livre de aviso e outra que trate apenas como avisos e permita que você trabalhe mesmo que alguém introduza um aviso.