Dela via


Porqué no debo utilizar las clases de System.Drawing en aplicaciones ASP.NET

Con cierta frecuencia tenemos casos de soporte de aplicaciones ASP.NET que dan problemas debido al uso de las clases de System.Drawing. El uso de del namespace System.Drawing no está soportado desde una aplicación ASP.NET (o cualquier otro servicio de Windows), lo cual pilla por sorpresa a más de uno. El motivo es que System.Drawing utiliza las APIs de GDI/GDI+ que no han sido diseñadas para ejecutarse en un entorno de alta concurrencia y además requieren ejecutarse una sesión de Windows interactiva. Esta limitación está documentada en la referencia de MSDN para System.Drawing y GDI+.

En Windows Server 2003, Windows XP y anteriores, podíamos utilizar parte de la funcionalidad de GDI desde una aplicación ASP.NET siempre y cuando no se produjera interacción con el monitor ni con ningún driver de video. Es decir, se podían utilizar objetos simples (líneas, formas en 2D, colores sólidos, etc.) de forma soportada. Gráficos más complejos (por ejemplo gráficos en 3D) que utilizan GDI+ no estaban soportados en ningún caso, al margen de que la aplicación ASP.NET aparentemente pudiera llegar a funcionar. En todo caso mi recomendación es que si no sabes exactamente lo que estás haciendo, no utilices System.Drawing en tus aplicaciones ASP.NET nunca.

En Windows Server 2008 y Windows Vista, dado que los servicios ahora corren en la sesión 0 donde no se permite el acceso al driver de video (por diseño del sistema operativo), toda la funcionalidad de GDI+ deja de funcionar por completo ya que requiere acceso a dicho driver. En cierto modo esto es una ventaja ya que así no tenemos la falsa percepción de que nuestra aplicación está funcionando correctamente cuando no es así.

¿Pero entonces cuál es la forma correcta de crear/manipular gráficos desde una aplicación ASP.NET? No existe una respuesta sencilla, estas son algunas alternativas que se me ocurren:

· Desarrollar un ejecutable separado que corra en una sesión interactiva de Windows. Este proceso será el encargado de la generación/manipulación de gráficos, y se comunicará con el proceso de IIS mediante IPC (interprocess communication) .

· Migrar la lógica de generación de gráficos a una aplicación Silverlight (particularmente interesante en este aspecto es Silverlight 3 , que está actualmente en Beta 1).

Adicionalmente, y aunque no manipulemos gráficos en nuestra aplicación ASP.NET, todo el código de servidor relacionado con la interfaz gráfica de nuestra aplicación web debe moverse a su equivalente en HTML/CSS en lugar de utilizar código de servidor. Es decir, por ejemplo es aconsejable sustituir este tipo de código de servidor:

MyBase.BackColor = Drawing.Color.FromArgb(255, 255, 255)

Por su equivalente en HTML/CSS combinado con código de servidor:

<style type="text/css">

.whitebackground { background-color:#ffffff;}

</style>

MyBase.CssClass = "whitebackground";

Lo dicho, evitad System.Drawing en vuestras aplicaciones ASP.NET. Hasta la próxima.

- Daniel Mossberg