Formas de ejecución de FxCop

Ejecución Manual

Si uno utiliza la versión standalone de FxCop, tiene en principio 2 alternativas: utilizar la interface de gráfica o la de línea de comandos.Pero hay que tomar en cuenta que mientras la interface de linea de comandos solo puede ejecutar análisis, la interface gráfica además de ejecutar análisis, permite crear proyectos de FxCop (.fxcop) con configuraciones específicas que incluyan conjuntos particulares de reglas y algunos otros parámetros específicos para la ejecución del análisis. Al mismo tiempo ocurre que la interface de línea de comando soporta  algunos opciones que la interface gráfica no, por ejemplo rulesets (.ruleset)

Otra forma de ejecutar análisis FxCop en forma manual es si uno cuenta con una version de Visual Studio que tenga la funcionalidad de Code Analysis incorporada. Es ese caso, pueden configurarse las reglas a aplicar desde las propiedades del proyecto y luego disparar el análisis desde el menú contextual del proyecto.

Ejecuación integrada a la compilación

Si uno cuenta con una versión de Visual Studio con la funcionalidad de Code Analysis incorporada, entonces también tiene opción de modificar los archivos de proyecto (.csproj) para que se dispare el análisis de código en cada compilación.

Ejecución con MSBuild

Esta opción es mi prefedida pues es independiente del Visual Studio lo cual la hace ideal a la hora de utilizar un build server. Básicamente consiste en generar un build script de MSBuild con una tarea de que se encargue de invocar a utilitario de linea de comando de MSBuild. Tiene un pequeño issue pues ni MSBuild ni FXCop proveen una tarea para ejecutar FxCop dentro de un script de MSBuild, por ello es necesario utilizar MSBuildExtensiónPack. Los interesado en esta opción pueden darle un vistazo a este build script que muestra un ejemplo (ver el target RunCodeAnalysis).

FxCop y Visual Studio

Continuando con la cuestión de análisis de código, quiero dedicar algunas líneas a estas dos herramientas. Como mencioné anteriormente,  Visual Studio ha incorporado nativamente a FxCop, pero he aquí algunos detalles curiosos:

  • No todas las ediciones de Visual Studio incorporaron FxCop, en particular las ediciones Professional no lo incorporaron hasta la version 2012 (nótese la diferencia entre version: 2008, 2010, 2012, etc  y edición: personal, professional, ultimate, etc).
  • Dentro de Visual Studio no hay ninguna mención a explícita a FxCop, sino que en los menús figura como Code Analysis, pero internamente es FxCop (pueden verse los assemblies dentro de la carpeta de Visual Studio).
  • Aún es posible descargar FxCop y utilizarlo de manera independiente al Visual Studio.
  • El FxCop independiente y el incluido en el Visual Studio no son exactamente lo mismo. Entre las diferencias hay algunos conjuntos de reglas adicionales que vienen con Visual Studio que no estan en el FxCop independiente.

Los puntos anteriores hacen que dependiendo de la versión específica de Visual Studio con la que uno cuente, la forma ejecutar el análisis de código sea diferente. en próximos post daré más detalles sobre esto.

Open source: new versions

In the last couple of weeks some new versions of open source projects have gone live.

In my opinion  the most interesting one is the first RTM release of Linq provider for NHibernate (NHibernate.Linq), at the moment it is a separete download, but it seems that it will be part of NHibernate’s Core package in future releases. [read more]

Also related to NHibernate, on July 14 it was published Castle Active Record 2.0 beta 1. It includes integration with NHibernate Search, basic Linq support and a feature to enable in-memory test. [read mode]

Spring Framework Team has schedule the release of Spring.Net 1.3 RC1 for July 29th, followed by the GA version on August 10th. [read more].

Finally, Sharp Architecture released the first RTM version on July 15th. [read more]

I hope to have some time during this week to show some examples of the new features of these new releases.

Enjoy it!

Something is changing…

Over the last two years some interesting things have happened in the .net community, among these things I would like to highlight the followings:

  • Greater interest in Domain Driven Design in contrast to the traditional MSDN Data driven way. This has stimulated the adoption of certain design techniques like DI and AOP among other.
  • As a consequence of the previous point there has been a wider adoption and diffusion of open source tools (beyond the P&P application blocks). Tools like NHibernate, Castle and Spring.Net have proven to be high quality products providing efficient solutions for typical problems in enterprise development. Event Microsoft (in a certain way) has recognized these facts, I think ASP.NET MVC is an example of this.
  • Massive adoption of agile development practices like continous integration, unit testing, pair programming and iterative development among others.

I think that evidence of these facts are the creation of the ALT.NET community and the publication of the excellent book “Foundations of Programming” by Karl Seguin.
I see this as great progress for the maturity of the community and the quality of its developments.

Embedded Resources

Sometimes your assembly on runtime depends on a file, like a image or a simple text file. To manage this file, you could store its location in the application configuration file, and then load your file by reading its location from configuration. Another option is to embedded the file as a resource in your assembly and then use the following code snippet to load it.

System.IO.Stream s = this.GetType().Assembly.GetManifestResourceStream(“NameOfTheFile”);

Lets see an example. Suppose an assembly called Model.dll that requires a file called TextFile.txt that is part of the same visual studio project. First of all you should define that file as an embedded resource (properties->build action = embedded resource). Then in your code, when you need to access this file you can load it this way:

System.IO.Stream fileStream = this.GetType().Assembly.GetManifestResourceStream(“Model.TextFile.txt”);
System.IO.StreamReader sr = new System.IO.StreamReader(s);
string fileContent = sr.ReadToEnd();
fileStream.Close();

Note that the name of the assembly has been appended to the of the file. One you have read the contents of the file, remember to close the stream

Excepciones

Independientemente de la tecnología de programación utilizada en toda aplicación es posible distinguir dos tipos de excepciones las de aplicación y las técnicas.
Las excepciones técnicas son producto de fallos en la infraestructura como ser falta de conectividad, caída de un servidor, etc.
Por su parte las excepciones de aplicación son producto de alguna acción incorrecta por parte del usuario y a grandes rasgos es posible clasificarlas en dos grupos: violaciones de formato (ingreso de un carácter en un campo numérico) y violaciones de reglas de reglas de negocio (alta de una entidad con un identificar repetido).
La distinción entre estos tipos de excepciones es necesaria ya que el comportamiento de la aplicación varia en base a estas.
Generalmente ante una excepción técnica la aplicación suele interrumpir la actividad del usuario mostrándole un mensaje del estilo “No es posible completar la operación requerida, por favor intente más tarde”, sin hacer mayor distinción en el tipo particular de excepción.
Por su parte, ante excepciones de aplicación, el usuario suele recibir un mensaje más específico, indicándole el error que ha cometido y dándole la posibilidad de corregir el error cometido sin necesidad de volver a comenzar con la con la actividad que se encontraba desarrollando.
Otra diferencia entre estos tipos de excepciones radica en el loggueo de las misma. Las excepciones técnicas siempre se logguean, llegando incluso a generar notificaciones a los administradores del sistema, mientras que las excepciones de aplicación no suelen ser loggueadas (salvo por cuestiones de auditoría para detectar usos indebidos del sistema).
En el caso particular de .NET, las excepciones técnicas suelen ser subclases de SystemException, mientras que las excepciones de aplicación lo son de ApplicationException.

Toolkit de introducción a .net

Un buen punto para empezar a introducirse en el mundo .net es el programa del desarrollador 5 Estrellas:

http://www.mslatam.com/latam/msdn/comunidad/dce2005/

Este programa, va guiando al estudiante, de forma progresiva, comenzando casi de cero, y llegando incluso a exponer cuestiones de web services y conceptos de arquitectura.

Para poder ejercitar y seguir el curso a un buen ritmo, es necesario contar con el Visual Studio 2005. Si usted a un no cuenta con una versión del mismo, puede descargar el Visual Web Developer en forma gratuita de la siguiente ubicación.

http://msdn.microsoft.com/vstudio/express/downloads/

Finalmente es importante que gradualmente y al menos una vez por semana visite los siguientes sitios de referencia:

http://www.microsoft.com/practices

http://www.theserverside.net