Suprimir los warnings de FxCop para un proxy WCF

Qué “antiestético” es el código con warnings, ¿verdad? Una de las cosas que más me llamó la atención, y tengo que reconocer que para mal, es la cantidad que saltan al pasar el FxCop sobre los proxies que genera Windows Communication Foundation. Da una sensación horrible, y cuando uno suprime los warnings, ver que al regenerar los proxies volvemos a la situación anterior, es tremendamente frustrante. Alguno estará pensando… ¿y qué hace este cenutrio pasando el analizador estático a código generado de forma automática? Bueno… mi problema es que no puedo elegir… al activar el análisis de código en las propiedades de un proyecto, se activa sobre todos los fuentes… incluidos los proxies. No puedo vivir sin FxCop, y tampoco puedo vivir con los warnings… supongo que hay amores que matan.


Hoy he estado buscando una forma de suprimir los warnings sobre los proxies sin que al regenerarlos se borren las supresiones, y he aquí que he dado con una receta para el éxito.


El truco consiste en poner las supresiones en el “GlobalSupressions.cs”. Los que uséis FxCop “a secas”, podéis hacer esto de una forma bastente sencilla… sólo hay que seleccionar el error y tras hacer click con el botón derecho, seleccionar “Copy As -> SuppressMessage”. Por desgracia, los que tenemos el FxCop integrado en Visual Studio 2005, no tenemos esta opción (nos la han prometido para Visual Studio Orcas).


No todo está perdido… todavía hay una solución. Solo, tenemos que actuar de la siguiente forma:



  • Suprimimos el error que ha detectado el analizador de código sobre el proxy. Esto meterá un atributo “SupressMessage” sobre el punto en el que se ha detectado el error. Nos fijamos en si el SupressMessage está sobre una clase, o sobre un método.

  • Quitamos el SupressMessage del proxy, y lo copiamos en el GlobalSupressions… poniéndole como prefijo “assembly”. Es decir:

    [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(“Microsoft.Usage”, “CA2239:ProvideDeserializationMethodsForOptionalFields”)]

  • Ahora tenemos que indicar dónde se encuentra el error original. Para eso, debemos especificar cual era el ámbito de la regla FxCop que ha saltado. Si ha saltado sobre una clase, el ámbito es “type”, y si ha saltado sobre un método, es “method”. Añadimos el ámbito por medio del parámetro “Scope” del atributo SuppressMessage:

    [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(“Microsoft.Usage”, “CA2239:ProvideDeserializationMethodsForOptionalFields”, Scope = “type”]

    o por ejemplo…

    [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(“Microsoft.Design”, “CA1051:DoNotDeclareVisibleInstanceFields”, Scope = “member”]

  • Por último, tenemos que indicar el punto en el que se encontraba el error. Para eso, utilizaremos el parámetro de nombre “Target”, en combinación con el siguiente valor:


    • Si se trataba de una clase, se indica el nombre totalmente cualificado de la clase (con namespace)

    • Si se trataba de una propiedad o un miembro, el nombre totalmente cualificado del miembro.

    • Si se trataba de un método, el nombre totalmente cualificado del método, sin incluir los nombres de los argumentos (sólo los tipos) e indicando el tipo de retorno al final (con dos puntos, al estilo de C++).

    • Por ejemplo:

      [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(“Microsoft.Usage”, “CA2239:ProvideDeserializationMethodsForOptionalFields”, Scope = “type”, Target = “Sisteplant.Captor.Terminal.EventsBrokerProxy.EventInfo”)]

      [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(“Microsoft.Design”, “CA1051:DoNotDeclareVisibleInstanceFields”, Scope = “member”, Target = “Sisteplant.Captor.Terminal.WorkplaceServiceProxy.GetInManufacturingOrdersRequest.dateTime”)]

      [assembly: System.Diagnostics.CodeAnalysis.SuppressMessage(“Microsoft.Design”, “CA1030:UseEventsWhereAppropriate”, Scope = “member”, Target = “Sisteplant.Captor.Terminal.EventsBrokerProxy.IEventsBroker.RaiseEvent(Sisteplant.Captor.Terminal.EventsBrokerProxy.EventInfo):System.Void”)]


Alguno podría tratar de suprimir varios errores tratando de establecer el Scope a “namespace”… pues bien, ni lo intentéis porque no funciona… hay que ir suprimiendo los errores uno por uno, y la lista de errores que os vais a encontrar es probablemente esta:


CA1030:UseEventsWhereAppropriate
CA1051:DoNotDeclareVisibleInstanceFields
CA1709:IdentifiersShouldBeCasedCorrectly
CA1711:IdentifiersShouldNotHaveIncorrectSuffix
CA2227:CollectionPropertiesShouldBeReadOnly
CA2239:ProvideDeserializationMethodsForOptionalFields



En fin, esperemos que la calidad del código generado automáticamente mejore… y no sólo haciendo que funcione el atributo “AutoGeneratedCode” que el svcutil añade a los proxies (y que por cierto, el FxCop no se toma muy en serio). Yo me pregunto… ¿tanto cuesta generar código que supere la regla CA1709?



Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *