Categoría: dotNet

Visual Studio 2013, esas cosas tan típicas de Microsoft

La semana pasada empecé a trabajar en un nuevo proyecto. Algo en teoría simple, un sitio web de tipo “informativo”, en el sentido que tiene mucha información y muy poca lógica de negocio. El líder técnico del cliente decidió que lo hicieramos con ASP.NET MVC 4, corriendo sobre .Net 4.5 y utilizando Visual Studio 2013 como entorno de desarrollo.

Cómo era de esperar a la hora de instalar Visual Studio 2013 me encontré con varias cuestiones que podrían resultar difíciles de creer para muchos desarrolladores, pero que no sorprenden a nadie que haya trabajado con tecnología Microsoft por un par de años.

La primera cuestión llamativa fue que apenas ejecuté el instalador, me encontré con un mensaje indicando que la aplicación a instalar (VS2013) no era compatible con mi sistema operativo (Windows 7). Me ví obligado a instalar el Service Pack 1 de Windows 7.

Una vez instalado el SP1, volví a ejecutar el instalador y me encontré con un mensaje que me indicaba que la instalación requeriría ~9 GB, si si, NUEVE GIGABYTES. Lo curioso es que yo estaba intentando instalar esta aplicación en una máquina virtual cuyo peso en ese momento era de unos 8 GB.
Como me costaba resignarme a que mi máquina virtual creciera tanto, hice una instalación personalizada en la que removí ciertos componentes que no eran de mi interés y logré bajar de 9 GB a 7 GB.

Continuando con la instalación, me encontré con otro mensaje que me indicaba que mi máquina no contaba con Internet Explorer 10 y que ello podría ocasionar que algunas funcionalidades de Visual Studio no estuvieran disponibles. Así que suspendí la instalación de Visual Studio e instalé la nueva versión de Internet Explorer.

Finalmente pude completar la instalación de Visual Studio 2013.

Crónicas de mi regreso a .net

Como mencioné hace un tiempo, he vuelto a desarrollar código con tecnología .net después de casi 2 años.

El proyecto en cuestión consiste principalmente en mantenimiento evolutivo de una aplicación desarrollada inicialmente en 2009 con Visual Studio 2008 y varios complementos como: AjaxControlToolkit, Web Service Enhancements 3.0, Crystal Reports y Enterprise Library 3 entre otros.  Un detalle no menor es que la aplicación ha estado congelada funcional y técnicamente desde 2010, por lo que los mencionados componentes siguen aún en uso.

La aplicación consiste en un producto ofrecido como servicio y que se encuentra actualmente en funcionamiento. La empresa que desarrolló este producto/servicio fue adquirida por otro empresa más grande y a partir de esto el nuevo dueño de producto ha decidido potenciar este producto/servicio, lo cual requiere el desarrollo algunas nuevas funcionalidades y la modificación de algunas otras ya existentes.

Como parte de mi backlog de trabajo estan como puntos más prioritarios:

  1. Armar la infraestructura de integración continua y despliegue automático, de cara poder liberar funcionalidad de forma frecuente.
  2. Implementar una nueva funcionalidad estratégica para el negocio.
  3. Actualizar la solución a net 4.5 y refactorizar algunos componentes.

Respecto a (1) he logrado interesantes avances que compartí hace un tiempo en un screencast.

Respecto a (2), la funcionalidad está aún en desarrollo y me resultó muy interesante pues tuve la chance de experimentar con algunas técnicas y herramientas para trabajo con código legacy (ah, si me olvidé de mencionarlo, la solución casi no tiene test automatizados).

Sin duda una de las cosas que más interesante me resultó fue el uso de Dapper para facilitar el acceso a la base de datos. Resulta que el acceso a la base de datos estaba hecho de manera cuasi ad-hoc utilizando Ado.net, datasets y store procedures, artefactos que no me resultan para nada felices. Sumado al hecho de que la última vez que escribí SQL a mano fue en 2005, desde entonces siempre he utilizado algún tipo de ORM para todas las operaciones tipo CRUD. Esta herramienta Dapper es muy simple, básicamente provee un conjunto de métodos de extensión sobre la clase DBConnection que facilitan el mapeo de objetos. No me animo a calificarlo como ORM, pues carece de ciertas funcionalidades como lazy loading y cache, pero más allá de eso creo que es una alternativa muy interesante cuando uno tiene que trabajar sobre una base de datos ya existente. Prometo dedicar otro artículo para contar más detalles sobre Dapper.

Por otro lado, si bien utilicé la técnica de inyección de dependencias, no utilicé ningún framework para ello, pues en el contexto de la funcionalidad que desarrollé introducir un nuevo framework era más complejo que  resolver la inyección de forma manual.

Issue with Internet Explorer 11 and Asp.Net Webforms

Some time ago Microsoft released Internet Explorer 11 and some of the users of a web applications I am working on, reported that they were not able to use the web application, they clicked some buttons and nothing happend.

After installing IE11 I was able to reproduce the issue and find root cause: asp.net was not generating the Javascript files required by the webforms controls. These strange behaviour was caused because asp.net did’t recognize the web browser that was sending the request (IE11).

This problem with a recommended solution is explained here by Mr. Hanselman.

In our case we just added a browser definition file to fix the problem. We know this is not the better solution, but we are about migrating to ASp.NET 4.5 that has a built-in fix for this  issue.

It is incredible that the same issue happened when IE10 was released.

NHibernate vs. Entity Framework: opiniones encontradas

En estos dias estoy arrancando un proyecto en .NET. Dado que estuve un poco alejado de este ecosistema por un tiempo, escribí un mail a un par de colegas de confianza consultándoles sobre cual de estos 2 ORMs utilizar.Las respuestas que recibí me hicieron reir bastante, cito textualmente:

“Nhibernate… EF es como los muñecos de una torta de casamiento, no se comen, son decorado.”

“Si la base es SQL server, andá por EF, no te compliques. Sino, anda por nhibernate pero con sharp-architecture.”

“NHibernate (EF sigue siendo una mentira)”

“ORM: Entity Framework, se que nhibernate ha mejorado mucho, pero EF con SQL anda muy bien.”

“ORM: EL DILEMA! Desde SW que no uso EF, y la verdad que me acostumbre a NHibernate, si te acordás de cuando lo usabamos en aquellas bellas épocas, es mejor aún. Con respectoa EF, esta última versión recién trae fluent mapping, no?”

También les consulté por inyectores de dependencias y las respuesta también fueron variadas, pero todas estuvieron de acuerdo en un punto: no a MEF.

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.

Análisis de Código en .Net

Al hablar de análisis de código en .Net es necesario diferenciar entre Source Analysis y Code Analysis.

Con Source Analysis nos referimos al análisis del código fuente escrito por el programado (típicamente en C#) el cual se realiza con la herramienta StyleCop.

Con Code Analysis nos referimos al análisis del byte code (MSIL) generado como resultado del proceso de compilación. La herramienta para esto es FxCop.

Ambas herramientas funcionan en base a un conjunto de reglas que pueden personalizarse e incluso extenderse. Si bien estas herramientas trabajan sobre distintos artefactos y tienen distintos objetivos, hay ciertos puntos en los que se superponen. Para entender esto analicemos 3 situaciones “incorrectas”:

  • Una clase escrita en C# nombrada todo en minúsculas, es una situación que seria detectada por StyleCop pero no por FxCop
  • Una clase que oculta un método declarado en una clase base, es una situación que será detectada por FxCop, pero no por StlyeCop
  • Un método con 20 parámetros, es algo que puede ser detectado tanto por StyleCop como por FxCop

Inicialmente ninguna de estas dos herramientas venia integradas con Visual Studio y debian ser descargadas e instaladas por separado. En la actualidad StyleCop continua en esta situación, pero no FxCop, que fue incorporado nativamente a Visual Studio en la versión 2008 (o puede que sea 2010, no estoy seguro).

Continuará…

Visual Basic migration

One more time this morning I have been asked about VB6 to VB.Net migration. I have my opinion about this topic.

If you have a VB6 application that is working well and that maintainance is relativaly easy, then, why do you want to migrate? Just because .net is cool?, no that can’t be a reason. The reason that I have started hearing these days is: “Microsoft won’t give us support for VB6″. Ok, that is a good reason, but there is still another questions to be answer:

A) Do you want the same application (from user perspective and from technical perspective) running in a new platform?

or

b) Do you want to take advantage of the capabilities of the new platform?

If you answer is B, then I most of the cases you don’t need a migration, you need to build a new system, maybe you can reuse some assets like database schema, some stored procedures, etc.

But if your answer is A, then there are some useful resources you can count on. First of all lets hear the voice of Patterns & Practices Group at Microsoft: Guide for upgrading VB6 applications to VB.Net and VB6 to VB.net upgrade assessment tool. I think these resources are a good starting point to understand the implications of the epic.

There also some interesting materials provided by Artinsoft (a company specialized in software migrations) . They have developed a tool to automate the migration process and they have also written some articles about it: Design application migration strategy and some more specific ones.

Hope this help.

VS2008 extension for SharePoint 2007

Last week I started a development project based on SharePoint 2007 and for the first time for this kind of projects I am using Visual Studio 2008 and the corresponding extensions for SharePoint. Among other things, these extension add some projects templates. Yesterday I noticed that these project templates are class library projects, but with a particular behavior. When you right click on the project file there is a “Deploy” option, witch does not exist in the case of regular class library projects. At first I thought that it was because of some properties in the configuration of the project, but I checked it and there was…nothing. So I opened the project file with a text editor and I noticed that the SharePoint project file had the following additional line:

<ProjectTypeGuids>{593B0543-81F6-4436-BA1E-4747859CAAE2};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

It seems that this line is the magic item that adds the “Deploy” option in the VS project file menu. I will try to get some more information about this curiosity.

Error handling in Web Services (ws-part 4)

This post wasn’t part of the original series, but I have decided to add it because of a project I am working on these days.

Most of the times I have been involved in the server side of web services, developing web services, but in this opportunity I am consumer of web services.

When reviewing the technical specs of the web services I have to consume I found that each web service returned a complex type that contains the following fields:

  • Result: an integer that represents the result of the invocation, (1) successful invocation, (2) Invalid parameters, (3) Internal service error, and so on.
  • Errors: in case the result be (2) it details the name of the parameters that are not valid.
  • Data: the business information expected as the result of the invocation.

This approach is not bad, but I feel it like been reinventing the wheel. Maybe it is because of my object-oriented programming background. I am used to use exceptions to handle errors. Most of the technologies that give support to soap protocol provides a way to work  with exceptions to manage errors.

When you call a web service and an error raises during the process, a soap fault message should be used to communicate the error. This fault message contains:

  • Code: that allows the fault to be classified in one of the following categories: VersionMismatch, MustUnderstand, DataEncodingUnknown, Sender and Receiver.
  • Reason: provides a human-readable explanation of the fault
  • Node: provides information about which SOAP node on the SOAP message path caused the fault to happen
  • Role: identifies the role the node was operating in at the point the fault occurred.
  • Detail: is intended for carrying application specific error information

No matter what technology you used to work with SOAP, most of them provide a class to represent a Soap Fault, that is typically called Soap Exception. In the case of .NET there is a SoapException. This way if you are using .NET to consume a web service using Soap, .NET will generate a proxy object for you to call the web service, when you call this service you should do it inside a try-catch block adding 2 catch statements one catch for a SoapException and another catch statement for a System.Net.WebException, in case that no connectivity can’t be established.