Category Archives: .NET

Uso de App.Config en aplicaciones de consola o Win Forms en .NET

Es muy común en nuestras aplicaciones el tener que extraer ciertas variables de configuración a un fichero externo para que se puedan modificar sin necesidad de volver a publicar la aplicación (como por ejemplo rutas que varían en función del servidor en el que publicas la aplicación, cuentas de correo para envíos que pueden cambiar su contraseña, cadenas de conexión, etc…)

En web ya tenemos el famoso Web.Config y su uso es bastante común para cualquier desarrollador web por lo que nos vamos a centrar en este sencillo artículo a cómo añadir un fichero de configuración a una aplicación de escritorio, escribirlo, leerlo y posteriormente modificarlo desde el bloc de notas.

 

Crear el fichero de configuración

Lo primero que debemos hacer es agregar el fichero de configuración a nuestra solución. Para ello nos vamos al explorador de soluciones de nuestro Visual Studio > Botón Derecho > Add > New Item > Application Configuration File.

 

 

Se añadirá un fichero XML con una estructura similar a la del Web.Config en el que podremos ir añadiendo las variables que queramos extraer añadiendo entradas al tag “appSettings” como el ejemplo siguiente:

 

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="mailEnvio" value="info@compilando.es"/>
    <add key="servidorEnvio" value="mail.compilando.es"/>
  </appSettings>
</configuration>

 

 

Leer el fichero de configuración desde la apliación

Una vez creado el fichero de configuración y añadidas las variables de configuración que queramos basta con hacer uso de la clase ConfigurationManager para leer el valor de las misma desde el código de nuestra aplicación:

 

 

string mailEnvio = ConfigurationManager.AppSettings["mailEnvio"];

 

 

Recuerda que has de utilizar el espacio de nombres “System.Configuration” (si no te aparece la clase es porque te falta añadir la dll al proyecto. Vete a Referencias > Añadir Referencia y en la pestaña de .NET busca System.Configuration y añadela al proyecto).

 

Publicar y Modificar la configuración del fichero desde fuera del Visual Studio

Una vez terminada y publicada nuestra aplicación (para este caso la llamaremos “Ejemplo”) tendremos el fichero ejecutable “Ejemplo.exe” que será el que arranque nuestra aplicación de consola o Win Forms y, junto a él, tendremos otro fichero llamado “Ejemplo.exe.config”

Este fichero es el fichero de configuración de la aplicación y se puede abrir perfectamente con el Bloc de Notas y editar los valores del XML para cambiar las variables de configuración si necesitar de recompilar la aplicación.

Así, en este ejemplo, podríamos cambiar el mail desde el que nuestra aplicación envío tan solo editando este fichero sin necesidad de abrir el Visual Studio lo que nos da una flexibilidad mayor a la hora de publicar y distribuir nuestra aplicaciones de escritorio.

 

Nos vemos Compilando!!

Gestión de Errores en ASP .NET: customErrors y Error Handling en Global.Asax

Uno de los aspectos más importantes a tener en cuenta cuando se pasa a producción una aplicación es como vas a tratar los posibles errores que ocurran en ella.

Por defecto, si no modificamos nada y ocurre un error sin controlar, la aplicación nos mostrará una página con el siguiente texto:

 

Server Error in ‘/’ Application.


Runtime Error

Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed remotely (for security reasons). It could, however, be viewed by browsers running on the local server machine. 

Details: To enable the details of this specific error message to be viewable on remote machines, please create a <customErrors> tag within a “web.config” configuration file located in the root directory of the current web application. This <customErrors> tag should then have its “mode” attribute set to “Off”.

 

 

Este mensaje nos indica que ha ocurrido un error y no se muestra al visitante debido a la configuración del Web.Config que por defecto viene así:

 

<configuration>
    <system.web>
        <customErrors mode="Off"/>
    </system.web>
</configuration>

La forma más rápida para poder ver el error es cambiar el “RemoteOnly” por “Off” pero esto no es para nada recomendable ya que muestra los errores a cualquier visitante de la web pudiendo poner en entredicho la seguridad del sistema.

La tercera configuración que permite el apartado “customErrors” es redirigir a una página específica de error y luego guardar el error en un fichero de log o base de datos o bien enviarlo por mail. 

 

Este tutorial explica cómo implementar esta última opción:

Primero: Modificamos el Web.Config para activar los errores personalizados para que redirija a la página “error.aspx”:

<configuration>
    <system.web>
        <customErrors mode="On" defaultRedirect="error.aspx"/>
    </system.web>
</configuration>

Segundo: Creamos la página “error.aspx” para indicar al usuario qué debe de hacer. Como ejemplo os dejo la página de error personalizada que hicimos en Domitienda.com:

Tercero: Sobreescribir el método “Application_Error()” del fichero “Global.asax” (si no tienes ese fichero en tu proyecto lo puedes agregar). Este método se ejecuta cada vez que ocurre un error sin capturar. En este ejemplo vamos a enviar un mail con el error para que podamos revisarlo y solventarlo cuanto antes:

 

void Application_Error(object sender, EventArgs e)
{

	try
	{
		//Obtenemos el error
		Exception ex = Server.GetLastError();

		//Formateamos el correo con los datos del error
		string bodyMail = "Error en Aplicación<br/>";
		bodyMail+= "<br/>Fecha: " + DateTime.Now.ToShortDateString() + " " + DateTime.Now.ToShortTimeString();
		bodyMail+= "<br/>Descripción: " + ex.Message;
		bodyMail+= "<br/>Origen: " + ex.Source;
		bodyMail+= "<br/>Pila: " + ex.StackTrace;

		System.Net.Mail.MailMessage oMsg = new System.Net.Mail.MailMessage();
		oMsg.From = new System.Net.Mail.MailAddress("error@mydomain.com");
		oMsg.To.Add("webmaster@mydomain.com");
		oMsg.Subject = "Error en Aplicación";
		oMsg.Body = bodyMail;
		oMsg.IsBodyHtml = true;

		System.Net.Mail.SmtpClient smtp = new System.Net.Mail.SmtpClient("mail.mydomain.com");
		smtp.Credentials = new System.Net.NetworkCredential("error@mydomain.com","passCuentaCorreo");

		smtp.Send(oMsg);

		//Limpiamos el error 
		Server.ClearError();
	}
	catch(Exception errorEnEnvioDeError)
	{
		//En caso de fallar el envío de error podíamos probar un método alternativo como guardar "bodyMail" en un fichero de texto o en base de datos
	}
}

 

 

Con este sencillo método tendremos nuestra web protegida ante errores inesperados, el visitante verá una página de error más usable y el adminitrador de la web tendrá el mensaje de error en su buzón de correo inmediatamente para poder solventarlo cuanto antes.

Nos vemos Compilando!!

Creando la capa de datos: Entity Framework vs LINQ to SQL

Una de las cosas que más interés me ha generado durante mi vida como desarrollador es como conseguir una buena capa de persistencia, consistente, flexible y transparente para el nivel de aplicación sin mezclar consultas sql’s o crear manualmente clases que repiten funcionalidad y datos.

He trabajado con varias herramientas, desde las más rudimentarias clases estáticas con métodos que ejecutaban sql “a pelo” hasta clases generadas a mano que por debajo usaban una instancia de DataRow (que por cierto no es serializable y no se puede usar con servicios WCF); hasta que en el framework 4.0 de .NET se incluyó el Entity Framework (EF) y LINQ to Entities.

 

Pero antes, un poco de historia:

Ya en la versión 3.5 de .NET nuestros amigos de Redmond incluyeron una nueva herramienta de O/RM (object relational mapping) conocida como “LINQ to SQL”. Con LINQ to SQL podíamos modelar una base de datos relacional con clases .NET de forma automática lo que nos permitia seleccionar, editar, insertar o eliminar datos tan solo editando las clases y colecciones generadas.

Para poder trabajar con estas clases se añadió soporte para lenguaje “LINQ” (Language Integrated Query) que no es más que un modo de expresar consultas similares al sql normal contra cualquier colección (ya sea generado por el modelador de LINQ to SQL o bien creada manualmente). LINQ incluye tipado, comprobación de las consultas en tiempo de compilación, expresiones lambda y tipos anónimos e intellisense lo que lo convierte en un lenguaje para consultas mucho más potente que el sql clásico.

Con estas dos herramientas juntas podemos obtener una serie de clases generadas automaticamente de una base de datos y trabajar con ellas manipulando datos sin necesidad de escribir una sola linea SQL.

 

Más adelante, con la versión 4.0 de .NET se incluyó ADO .NET Entity Framework y su LINQ to Entities que ofrecía una nueva forma de modelar bases de datos en entidades de forma automática más compleja y flexible pero con un funcionamiento básicamente similar ya que también se trabaja mediante consultas LINQ.

 

Visto esto os preguntareis: “Pues tiene buena pinta pero…¿qué diferencias existen entre LINQ to SQL y Entity Framework?

Aunque son casi lo mismo LINQ to SQL y EF han tenido vidas paralelas y, hoy en día, EF se ha impuesto de manera aplastante. La gran diferencia es que LINQ to SQL se creó con la finalidad de ser un RAD (Rapid Application Development) por lo que se dejaron alguna cosas en el tintero que se solventaron con EF:

  • LINQ to SQL sólo permite conectarse a SQL Server y ser usado en C# o VB.NET. EF en cambio soporta varios proveedores como MySql, Oracle, SQL Server, XML, etc…
  • LINQ to SQL mapea cada tabla/vista como una clase o “entidad” sin permitir herencia, entidades lógicas o entidades de negocio. EF lo implementa completamente.

 

Como veis Entity Framewok está preparado para modelar la capa de datos de una forma más generica y flexible lo que nos permite abordar proyectos de mayor envergadura aunque si lo que buscamos es una forma rápida de modelar nuestra base de datos SQL SERVER y no necesitamos grandes florituras LINQ to SQL nos valdría perfectamente.

En futuras entradas explicaré de forma más practica como modelar una base de datos y como hacer las típicas consultas (Select, Insert, Update, Delete) con Entity Framework.

 

Nos vemos Compilando!