"Tratar todas las advertencias como errores excepto ..." en Visual Studio

En Visual Studio, puedo seleccionar la opción "Tratar advertencias como errores" para evitar que mi código se compile si hay advertencias. Nuestro equipo usa esta opción, pero hay dos advertencias que nos gustaría mantener como advertencias.

Hay una opción para suprimir las advertencias, pero QUEREMOS que aparezcan como advertencias, para que eso no funcione.

Parece que la única forma de obtener el comportamiento que queremos es ingresar una lista de cada número de advertencia de C # en el cuadro de texto "Advertencias específicas", excepto los dos que queremos que sean tratados como advertencias.

Además del dolor de cabeza de mantenimiento, la mayor desventaja de este enfoque es que algunas advertencias no tienen números, por lo que no se pueden hacer referencia explícitamente. Por ejemplo, "No se pudo resolver esta referencia. No se pudo ubicar el ensamblado 'Datos ...'"

¿Alguien sabe de una mejor manera de hacer esto?

Aclarando para aquellos que no ven de inmediato por qué esto es útil. Piense en cómo funcionan la mayoría de las advertencias. Te dicen que algo está un poco fuera del código que acabas de escribir. Tarda unos 10 segundos en solucionarlos, y eso mantiene el código base más limpio.

La advertencia "Obsoleto" es muy diferente de esto. A veces arreglarlo significa simplemente consumir una nueva firma de método. Pero si una clase entera es obsoleta y su uso está disperso a través de cientos de miles de líneas de código, podría tomar semanas o más solucionarlo. No desea que la compilación se rompa durante tanto tiempo, pero definitivamente desea ver una advertencia al respecto. Este no es solo un caso hipotético, esto nos ha sucedido.

Las advertencias literales de "advertencia" también son únicas. A menudo quiero registrarlo, pero no quiero romper la compilación.

Puede agregar una WarningsNotAsErrorsetiqueta en el archivo del proyecto.

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

Nota: 612y 618ambas son advertencias sobre Obsoleto, no sé la diferencia, pero el proyecto en el que estoy trabajando informa Obsolete con la advertencia 618.

/ warnaserror / warnaserror-: 618

o más específicamente, en su caso:

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

esto debería tratar todas las advertencias como errores, excepto las que están en su lista separada por comas

¿Por qué quieres seguir viendo advertencias que no estás tratando como errores? Estoy confundido acerca de por qué esto es deseable, ya sea que los arregles o no.

¿Funcionarían dos archivos de compilación / solución diferentes, o un script para copiar uno y luego modificar el nivel de advertencia / advertencia? Parece que quizás quieras que algunas ejecuciones del compilador graznen, pero otras que quieras seguir.

Por lo tanto, diferentes compiladores parecen ser un buen camino a seguir. Puede hacer esto con diferentes objetivos: uno etiquetado como depuración o liberación y los otros etiquetados adecuadamente sobre las advertencias.

Estoy usando tratar advertencias como errores.

En casos excepcionales, cuando aparece una advertencia aceptable (es decir, que hace referencia a un miembro obsoleto o falta documentación en las clases de serialización XML), debe suprimirse explícitamente con #pragma disable (y, opcionalmente, podría proporcionarse una razón para no tener un código limpio) como un comentario a lo largo)

La presencia de esta directiva también permite averiguar quién aceptó esta violación de advertencia (por acción de "culpa" del control de versiones) en caso de que haya algunas preguntas.

¿Por qué no simplemente tener una regla que diga "Quien ingrese el código con cualquier advertencia dentro de él que no sea 612, 1030, 1701 o 1702 debe ir a la pizarra y escribir cien veces" No volveré a ingresar el código con advertencias rechazadas nuevamente. '"

advertencia de pragma (referencia de C #)

La advertencia de pragma puede usarse para habilitar o deshabilitar ciertas advertencias.

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

Me parece que el problema raíz es realmente una combinación de sus advertencias de tratamiento como errores, cuando claramente no lo son, y su política aparente de permitir registros que violen esto. Como usted dice, desea poder seguir trabajando a pesar de una advertencia. Solo ha mencionado algunas advertencias que desea poder ignorar, pero ¿qué pasa si alguien más en el equipo causó algún otro tipo de advertencia, que le tomaría igual de tiempo para solucionarlo? ¿No te gustaría poder ignorar eso también?

La solución lógica sería: 1) No permitir registros si el código no se compila (lo que significa que quienes crearon las advertencias tendrán que corregirlos, ya que en realidad, rompieron la compilación), o 2) tratar las advertencias como advertencias. Cree dos configuraciones de compilación, una que trate las advertencias como errores, que se pueden ejecutar regularmente para garantizar que el código no tenga advertencias, y otra, que solo las trata como advertencias, y le permite trabajar incluso si alguien más introdujo una advertencia.