visual-studio-2010 msbuild code-analysis fxcop

visual studio 2010 - Realización de análisis de código estático.NET 4.0(FxCop) con VS 2010 Professional



visual-studio-2010 msbuild (6)

Tengo VS 2010 Professional (que, a diferencia de Premium , no incluye el acceso a la configuración de Code Analysis dentro del IDE) y una solución C # 4 que contiene muchos proyectos. Quiero hacer un análisis de código estático como parte de la compilación de la solución.

Las posibles maneras que he identificado con la ayuda de SO y Google son:

  • Edite cada .csproj en la solución para incluir una invocación del FxCop 10 independiente como un evento Post-build. Pros: ocurre en cada compilación para cada proyecto que se reconstruye. Contras: Deben tomar medidas adicionales para garantizar que los nuevos proyectos tengan este especificado

  • Cree un nuevo proyecto o identifique un proyecto existente, que siempre se construye por última vez, debido a sus dependencias de proyecto. Asigne (solo) ese proyecto a un evento Post-build que ejecute FxCop en todos los ensamblados en la carpeta de salida (común). Pros: solo un archivo para actualizar y menos posibilidades de que los proyectos futuros no se analicen. Contras: los caprichos de las dependencias de compilación pueden significar que esto no funciona

  • Actualice todas las instancias VS de los desarrolladores con un complemento o macro que ejecute FxCop después de cualquier compilación. Realmente no me gusta esta idea en absoluto.

¿Hay alguna otra opción que sea claramente mejor que cualquiera de las anteriores? ¿Hay alguna advertencia u observación que deba tener en cuenta para hacer uno de los trabajos anteriores?

También quiero que FxCop se ejecute como parte de una compilación con MSBuild 4.0 en un servidor de compilación. ¿Cuál de las opciones me permitirá reutilizar los conjuntos de reglas de análisis de código entre compilación de escritorio y compilación de servidor bulid?

Ya he leído preguntas ya existentes, pero no idénticas, que incluyen:

Cree una actividad de compilación personalizada (que se ejecuta en función de una propiedad que establecemos a través de la definición de compilación):

  1. Mi actividad personalizada busca todos los archivos * .csproj en la carpeta raíz.

  2. Actualiza todos los archivos csproj para agregar la propiedad "

    cierto

  3. Guarde el archivo csproj.

  4. Ahora esto hará que el análisis del código se ejecute cuando lo compile.

Esto significa que tenemos control sobre cuándo se debe ejecutar el análisis del código o no. No tenemos que ejecutarlo cada vez que construimos el código.

Simplemente lea que no tiene el VS premium, pero puede seguir el mismo proceso para actualizar el evento de compilación de la publicación del archivo csproj durante el tiempo de compilación.

No he usado FxCop por un tiempo, pero si tienes muchos proyectos, sospecho que ejecutarlo una vez por cada proyecto, en lugar de solo una vez al final, será doloroso. Podrías probar (o al menos comenzar) algo como esto . En pocas palabras, tiene un proyecto súper, con objetivos que dependen de la construcción de toda la solución, seguido de ejecutar FxCop (o pruebas unitarias, etc.). Invoca el proyecto superior utilizando un archivo por lotes del Explorador de soluciones.

Es similar a su segunda sugerencia, pero no tendrá ninguna dependencia en el orden de compilación, y no requiere tocar el violín con nuevos proyectos. Desafortunadamente, su encarnación actual rompe los atajos normales para construir desde dentro de VS, y probablemente será fácil pasar por alto accidentalmente, pero podría ser posible refinarlo.

También podría estar más limpio y mejor integrado con VS para usar un objetivo MSBuild para ejecutar FxCop, en lugar de un paso posterior a la construcción.

Para integrar FxCop como parte de la compilación scipt (MSBuild) utilizo la tarea FxCop de MSBuild.Community.Tasks . Usando FxCop, creo un proyecto FxCop (FxCopProject.FxCop) que define las reglas a usar y los ensambles a examinar.

<?xml version="1.0" encoding="utf-8"?> <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <MSBuildCommunityTasksPath>$(MSBuildProjectDirectory)/vendor/MSBuild.Community.Tasks.v1.3.0.504</MSBuildCommunityTasksPath> <FxCopDir>vendor/Microsoft Fxcop 10.0</FxCopDir> </PropertyGroup> <Import Project="$(MSBuildCommunityTasksPath)/MSBuild.Community.Tasks.Targets"/> <Target Name=''FxCopReport''> <FxCop ToolPath=''$(FxCopDir)'' ProjectFile=''FxCopProject.FxCop'' AnalysisReportFileName=''FxCopReport.xml'' /> </Target> </Project>

Sé que esta es una vieja pregunta, pero la mejor opción es usar SonarQube con el complemento C # para hacer su análisis. Esto maneja FxCop como una de las opciones de análisis, además de poder hacer análisis de StyleCop y ReSharper (usando el corredor de línea de comandos gratuito) y compila en una sola interfaz web.

Lleva un poco de tiempo configurar el primer proyecto, pero la configuración de proyectos posteriores es muy similar y puede ser activado por su servidor de CI.

Una alternativa a FxCop sería usar la herramienta NDepend que permite escribir reglas de código sobre C # LINQ Queries (es decir, CQLinq) . Descargo de responsabilidad: soy uno de los desarrolladores de la herramienta

Se proponen más de 200 reglas de código por defecto. Personalizar las reglas existentes o crear sus propias reglas de código es sencillo gracias a la bien conocida sintaxis C # LINQ.

Las reglas se pueden verificar en vivo en Visual Studio y en el tiempo de proceso de compilación, en un informe HTML + javascript generado .

Utilicé Hudson como un servidor de compilación que realizaría análisis de código luego de compilar aplicaciones .NET. Para usarlo con este fin, deberá instalar dos complementos:

  • Plugin de MSBuild para construir aplicaciones .NET.
  • Complemento de violaciones que informa los resultados del análisis de código y es compatible con FxCop y StyleCop.

Hudson necesitaría estar configurado para ejecutar FxCop y StyleCop, pero esto no es muy difícil de hacer usando archivos por lotes. El beneficio es que ninguno de sus archivos de proyecto necesitaría ser configurado, ya que el análisis del código se realizaría externamente; es decir, no a través de Visual Studio.

Puede configurar Hudson para realizar el análisis de código como una tarea diaria o incluso en cada cambio de sus aplicaciones. Luego, todos en su equipo de desarrollo podrían ver los resultados del análisis de código a través de Hudson para determinar si han cometido alguna infracción.