Escribiendo una regla de análisis de código para VSTS 2008
FxCop es una herramienta Open Source que ayuda al análisis de ensamblados de código mediante reglas y reporta información relacionada de esos ensamblados, la cual puede referirse a rubros como el de seguridad, diseño, rendimiento, todo aquello relacionado a reglas aplicables a los ensamblados (para mas información).
Después de conocer que esta herramienta viene integrada en la versión Team System de Visual Studio .NET 2008 (en realidad ya venía integrada desde versiones anteriores) en la empresa donde laboro decidieron ajustar las reglas o estándares de codificación internas utilizadas, a todo aquel ensamblado generado en los proyectos.
El objetivo era generar código estandarizado y que mejor que el Code Analysis para lograrlo y usarlo para crear políticas de generación de buils, es decir, no permitir compilar el proyecto si no cumplimos con los estándares internos.
A partir de este párrafo verán algo de lo que pude realizar para crear una regla de análisis de código que verifique el nombramiento de los elementos de interfaz grafica.
1. Crear biblioteca de clases
Nuestro primer paso será de los más sencillo, crear un proyecto de tipo biblioteca de clases que contendrá las clases que define la regla para verificar el nombramiento de los elementos de interfaz grafica de nuestras aplicaciones (es una buena práctica definir un archivo de tipo solución de proyecto y en esta ir agregando todos los proyectos que necesitemos).
2. Agregar referencias
Debemos de incluir nuestras referencias a la librería de FxCop que se encuentra dentro de la ruta: Archivos de programa\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop (podria variar dependiendo del idioma y sistema operativo y al menos en un XP en español es la misma). Estas representan el framework que contiene las clases necesarias para poder diseñar nuestra regla.
- FxCopSdk.dll. Para acceder a la interfaz IIntrospectionRule que permitirá identificar aquellas clases de ensamblados que son reglas de Code Analysis, que implementa la clase BaseIntrospectionRule.
- Microsoft.Cci.dll.
3. Crear la clase base
Para poder implementar los métodos de la interfaz IIntrospectionRule, es necesario crearnos una clase abstracta (que nosotros llamaremos BaseRule) que herede o implemente la clase BaseIntrospectionRule. Más o menos quedaría así:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | using System; using System.Collections.Generic; using System.Linq; using System.Text; using Microsoft.FxCop.Sdk; using Rules.Naming.Globales; namespace Rules.Naming { public abstract class BaseRule : BaseIntrospectionRule { protected BaseRule(string name) : base(name, Constantes.Config_Rules, typeof(BaseRule).Assembly) { } } } |
Noten que he agregado una clase (Constantes.cs) que contendrá aquellas variables constantes para nuestra regla. Yo ahí he colocado la variable que representara nuestro archivo de recursos (un archivo xml, pero aun no te preocupes por conocerlo, mas adelante lo podrás observar).
1 2 3 4 5 6 7 8 9 10 11 12 13 | namespace Rules.Naming.Globales { /// <summary> /// Clase estática que contiene los valores constantes. /// <summary> public static class Constantes { /// <summary> /// El nombre del recurso embebido. Xml que contiene las reglas. /// <summary> public const string Config_Rules = "Rules.Naming.Rules"; } } |
4. Crear la regla de Code Analysis
Bien, ¡estamos listos para crear nuestra regla!, habíamos comentado que nuestra regla validaría el nombramiento de elementos de interfaz grafica de nuestras aplicaciones, entonces como primer punto debemos de agregar una clase nueva a nuestro proyecto (es una buena práctica nombrar a la clase con un nombre que haga referencia a la regla). Nuestra clase se llamara VerifyGUINaming.cs y la definición se muestra a continuación.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | using System; using System.Collections.Generic; using System.Linq; using System.Text; using Microsoft.FxCop.Sdk; namespace Rules.Naming { /// <summary> /// Esta clase nos permitirá diseñar una regla para realizar análisis de código /// a los elementos de interfaz gráfica de la aplicación. /// <summary> public class VerifyGUINaming : BaseRule { public VerifyGUINaming() : base("VerifyGUINaming") { } } } |
Como se puede observar lo primero que tenemos que hacer es agregar la referencia a nuestra biblioteca de clases de FxCop y después hacer que la misma herede de la clase base (BaseRule.cs) que hemos definido (no olviden documentar todo lo que hagan). Hasta aquí ya se encuentra definida la regla, pero aun no hace nada jojojo!.
5. Implementando el metodo Check()
Empecemos con lo nice de esto. Debemos de implementar el método Check() que contiene la clase BaseIntrospectionRule que permitirá reportar cualquier problema (¿recuerdan al inicio del tutorial? ) referente a la definición y los deposita dentro de una clase ProblemCollection.
Nuestro código para verificar el nombramiento de un elemento de escritorio de tipo Button deberá de verse así:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 | /// <summary> /// Método que agrega a la colección de problemas en caso de no cumplirse la regla. /// <summary> /// <param name="member">Elemento a comparar.</param> /// <returns>Un problema en caso de haberlo.</returns> public override ProblemCollection Check(Member member) { Field campo = member as Field; if (campo != null) { string nombreControl = campo.Type.FullName; if (nombreControl.StartsWith("System.Windows.Forms.Button")) { if (!campo.Name.Name.StartsWith("btn_")) { Problems.Add(new Problem(GetResolution("btn_", "System.Windows.Forms.Button", campo.Name.Name))); } } else { return null; } } else { return null; } return Problems; } |
Si aun no sabes que es lo que recibe como parámetro (member) el método Check, entonces te puedo comentar que ese tipo representa los miembros que puede tener una clase, métodos, propiedades, eventos, delegados, etc. Existen otros elementos que analiza el método Check, pero como ya he escrito mucho sobre esto, tendrás oportunidad de echar un googlazo e investigar por tu cuenta.
6. Creando el esquema XML
Para dejar completa nuestra regla es necesario crear nuestro archivo XML que describirá información relacionada a aquellos problemas encontrados al momento de analizar el código del ensamblado, en otras palabras, el código mostrado determina si hay un problema, el archivo XML lo describe de mejor forma.
Como primer paso habrá que agregar a nuestro proyecto un archivo con extensión xml y escribir lo siguiente:
1 2 3 4 5 6 7 8 9 10 11 12 13 | <?xml version="1.0" encoding="utf-8" ?> <Rules FriendlyName="Code Analysis Rules"> <Rule TypeName="VerifyGUINaming" Category="Rules.Naming" CheckId="NR0001"> <Name>Nombramiento de elementos de interfaz gráfica</Name> <Description>Para el nombramiento de los elementos de interfaz gráfica el identificador del control se deberá escribir en minúscula anteponiendo al identificador un prefijo que indique el tipo de elemento grafico que es separado por un guión bajo. Esto ayudara a distinguir los elementos de interfaz grafica.</Description> <Url></Url> <Resolution>Reemplazar el identificador del control "{2}" por su correcto nombramiento de interfaz gráfica: "{0}".</Resolution> <MessageLevel Certainty="95">Error</MessageLevel> <FixCategories>Breaking</FixCategories> <Email>jramirezleyva@gmail.com</Email> <Owner>Roberto Ramírez</Owner> </Rule> </Rules> |
El nombre del recurso si bien recuerdan lo definimos en nuestra clase Constantes.cs y se indica en la clase base BaseRule.cs
Algo muy importante es decirle a nuestro proyecto que este archivo de reglas XML deberá de comportarse como un recurso embebido a nuestro ensamblado.
7. Usando nuestra regla de análisis de código
Hasta este paso lo que obtenemos como resultado es un ensamblado que contiene la definición de nuestra regla, y lo que debemos de hacer es probarla.
Para que esto sea posible debemos manualmente copiar nuestra regla (ensamblado) al folder de nuestra versión de Visual Studio, como el titulo dice que es para la versión VSTS 2008 nuestro folder se encuentra en esta dirección: C:\Archivos de programa\Microsoft Visual Studio 9.0\Team Tools\Static Analysis Tools\FxCop\Rules, normalmente lo único que cambia es la versión del Visual Studio.
Una vez finalizado esto, cerramos y abrimos nuestro Visual Studio. Tu puedes crear un nuevo proyecto a agregarlo a la solución para hacer la prueba de análisis de código, en este caso puedes agregar un proyecto de escritorio para revisar el elemento de interfaz grafica Button.
Ya que tengamos nuestro proyecto veremos sus propiedades y en la pestaña de análisis de código (Code Analysis) veremos algo muy similar a esto:
Dando por hecho que en nuestra aplicación de escritorio de prueba tenemos un botón sin el prefijo “btn_” en la forma y corriendo el Code Analysis en nuestra aplicación podemos ver lo siguiente:
Nota que lo que nos arroja el análisis de código en un problema de tipo Warning, dejando que nuestro proyecto compile, si al inicio hablamos de código estandarizado entonces deberemos de configurar nuestra aplicación para que no compile en caso de no cumplirse las reglas. Para esto lo único que debemos de hacer es darle a la regla un trato de error en nuestro archivo XML y en la configuración de las propiedades del proyecto habilitar las opciones de “Manejar la regla como error” y “Habilitar Code Analysis en el Build” como se muestra en la imagen:
Con esto no permitiremos compilar código si antes no cumplimos con nuestras reglas.
Espero que esto los ayude.
