Suprimir "nunca se usa" y "nunca se asigna a" advertencias en C#

visual-studio suppress-warnings

Question

Tengo un archivo HTTPSystemDefinitions.cs en el proyecto C # que básicamente describe el ISAPI de Windows más antiguo para consumo por código administrado.

Esto incluye el conjunto completo de Estructuras relevantes para el ISAPI no todas o que son consumidas por el código. En la compilación, todos los miembros de campo de estas estructuras están causando una advertencia como la siguiente:

El campo de advertencia ''UnionSquare.ISAPI.HTTP_FILTER_PREPROC_HEADERS.SetHeader'' nunca se asigna a, y siempre tendrá su valor predeterminado nulo

o

Advertencia El campo ''UnionSquare.ISAPI.HTTP_FILTER_PREPROC_HEADERS.HttpStatus'' nunca se usa

¿Se pueden desactivar con la #pragma warning disable ? Si es así, ¿cuáles serían los números de error correspondientes? Si no, ¿hay algo más que pueda hacer? Tenga en cuenta que solo tengo que hacer esto para este archivo, es importante que vea advertencias como estas provenientes de otros archivos.

Editar

Ejemplo de estructura: -

struct HTTP_FILTER_PREPROC_HEADERS
{
//
// For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
// Header names should include the trailing '':''. The special values
// ''method'', ''url'' and ''version'' can be used to retrieve the individual
// portions of the request line
//
internal GetHeaderDelegate GetHeader;
internal SetHeaderDelegate SetHeader;
internal AddHeaderDelegate AddHeader;
UInt32 HttpStatus; // New in 4.0, status for SEND_RESPONSE
UInt32 dwReserved; // New in 4.0
}

Answer 1

Los usuarios de C / C ++ tienen (void)var; para suprimir las advertencias de variables no utilizadas. Acabo de descubrir que también puede suprimir advertencias de variables no utilizadas en C # con operadores bit a bit:

 uint test1 = 12345;
test1 |= 0; // test1 is still 12345
bool test2 = true;
test2 &= false; // test2 is now false

Ambas expresiones no producen advertencias de variables no utilizadas en los compiladores VS2010 C # 4.0 y Mono 2.10.

Answer 2

Obtuve VS para generar el esqueleto de implementación para System.ComponentModel.INotifyPropertyChanged y los eventos se implementaron como campos que activaron las advertencias CS0067.

Como alternativa a la solución dada en la respuesta aceptada , convertí los campos en propiedades y la advertencia desapareció .

Esto tiene sentido ya que la sintaxis de declaraciones de propiedades sugar se compila en un campo más getter y / o métodos setter (add / remove en mi caso) que hacen referencia al campo. Esto satisface al compilador y las advertencias no se plantean:

struct HTTP_FILTER_PREPROC_HEADERS
{
//
// For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
// Header names should include the trailing '':''. The special values
// ''method'', ''url'' and ''version'' can be used to retrieve the individual
// portions of the request line
//
internal GetHeaderDelegate GetHeader {get;set;}
internal SetHeaderDelegate SetHeader { get; set; }
internal AddHeaderDelegate AddHeader { get; set; }
UInt32 HttpStatus { get; set; } // New in 4.0, status for SEND_RESPONSE
UInt32 dwReserved { get; set; } // New in 4.0
}

Answer 3

Otra "solución" para corregir estas advertencias es hacer public la estructura. Las advertencias no se emiten porque el compilador no puede saber si los campos se están utilizando (asignados) fuera del ensamblaje.

Dicho esto, los componentes de "interoperabilidad" generalmente no deberían ser públicos, sino internal o private .

Answer 4

Sí, estos pueden ser suprimidos.

Normalmente, me opongo a la supresión de advertencias, pero en este caso, las estructuras utilizadas para la interoperabilidad requieren absolutamente que haya algunos campos, incluso aunque nunca intentes (o puedas) usarlos, por lo que en este caso creo que debería estar justificado .

Normalmente, para suprimir esas dos advertencias, corregirías el código ofensivo. El primero ("... nunca se usa") suele ser un olor a código de las sobras de versiones anteriores del código. Tal vez el código fue eliminado, pero los campos quedaron atrás.

El segundo es generalmente un olor de código para los campos incorrectamente utilizados. Por ejemplo, puede escribir incorrectamente el nuevo valor de una propiedad a la propiedad misma, nunca escribiendo en el campo de respaldo.

Para suprimir las advertencias de "El campo XYZ nunca se usa ", debes hacer esto:

#pragma warning disable 0169
... field declaration
#pragma warning restore 0169

Para suprimir las advertencias de "El campo XYZ nunca se asigna, y siempre tendrá su valor predeterminado XX ", debe hacer esto:

#pragma warning disable 0649
... field declaration
#pragma warning restore 0649

Para encontrar esos números de advertencia usted mismo (es decir, cómo sé usar 0169 y 0649), haga esto:

• Compila el código como siempre, esto agregará algunas advertencias a tu lista de errores en Visual Studio
• Cambie a la ventana de Salida, y la salida de Compilación, y busque las mismas advertencias

• Copie el código de advertencia de 4 dígitos del mensaje relevante, que debería verse así:

  C: / Dev / VS.NET / ConsoleApplication19 / ConsoleApplication19 / Program.cs (10,28): advertencia CS 0649 : El campo ''ConsoleApplication19.Program.dwReserved'' nunca se asigna a, y siempre tendrá su valor predeterminado 0

Advertencia : según el comentario de @Jon Hanna , tal vez algunas advertencias estén en orden para esto, para futuros buscadores de esta pregunta y respuesta.

• Primero, y ante todo, el acto de suprimir una advertencia es similar a tragar pastillas para el dolor de cabeza. Claro, podría ser lo correcto a veces, pero no es una solución general. A veces, un dolor de cabeza es un síntoma real que no debe enmascararse, lo mismo con las advertencias. Siempre es mejor intentar tratar las advertencias fijando su causa, en lugar de simplemente eliminarlas ciegamente de la salida de compilación.
• Una vez dicho esto, si necesita suprimir una advertencia, siga el patrón que expuse arriba. La primera línea de código, #pragma warning disable XYZK , deshabilita la advertencia para el resto de ese archivo , o al menos hasta que se encuentre una #pragma warning restore XYZK correspondiente. Minimice la cantidad de líneas en las que deshabilita estas advertencias. El patrón anterior desactiva la advertencia para una sola línea.
• Además, como menciona Jon, es una buena idea comentar por qué estás haciendo esto. Desactivar una advertencia es definitivamente un olor a código cuando se realiza sin una causa, y un comentario evitará que los futuros mantenedores pasen tiempo preguntándose por qué lo hiciste o incluso quitándolo e intentando corregir las advertencias.