lunes, 21 de abril de 2014

Server Error in '/' Application. Runtime error .NET

Cuando montamos nuestro proyecto en el servidor de .NET (por fín!), y en medio de la alegría, el entusiasmo y motivación nos hacen sentir como que nuestro hijo va a ser presentado en sociedad, es cuando nos cae un balde de agua fría al ver el siguiente error en pantalla:


Hay muchas maneras de tomar este error, la que siempre recomiendo es, antes que nada: ir por un café!  Y luego seguir con los pasos básicos para atenderlo.

¿Por qué tengo este error, si en desarrollo y pruebas no estaba?


Realmente nunca un entorno de desarrollo, uno de pruebas y uno de producción son iguales (así te lo digan en medio de un juramento hipocrático). Por lo tanto, hay varias cosas que pudieron salir mal.

Lo que es necesario entender en este momento, es que realmente no estas viendo un error de tu aplicación, es un mensaje generalizado, que te dice que NO te va a mostrar el error, pero que "Hay un error" (pero no te lo va a mostrar, peró si está).  Entonces el primer paso, es configurar el montaje en el servidor para ver el detalle del "error de nuestro trabajo".

Algunas causas que generalmente producen este error son:
  1. La aplicación se ha construido para una versión diferente de Framework a la que está corriendo en el servidor.
  2. Falta un parámetro de configuración en el web.config y se está utilizando en el código de nuestro proyecto.
  3. Faltó subir un ensamblado .dll a la carpeta bin.
  4. Publicamos archivos .aspx que no concuerdan con los .dll de la carpeta bin.
  5. No se han borrado algunos archivos viejos .dll de versiones anteriores y ahora hay conflicto entre los nuevos .dll que hay en la carpeta bin
  6. Algunas de las librerías de terceros (.dll) están compiladas para una versión diferente de Framework que la del servidor en donde montamos nuestro proyecto.
  7. No hicimos pruebas antes de montar al servidor y el error siempre ha existido en nuestro código.
  8. El servidor no nos quiere. (Esta causa no está documentada en MSDN)

Haciendo trabajo de detectives.


Primero que todo, ese no es el verdadero error, hay que indagar para saber cuál ha sido el error, entonces estos son pasos para poder ver el verdadero error:
  1. Saber exactamente cuál es la versión del Framework .NET del servidor y puede ser cualquiera de las siguientes opciones: 2.0, 3.0, 3.5 y 4.0.  Dependiendo de la Versión, hay diferentes alternativas, pero la general es como la menciono a continuación.
  2. En el archivo web.config buscar la cadena (así no exista esta configuración, así debe estar por defecto)
     <customErrors mode="RemoteOnly" />
     
  3. Cambiar el valor de mode por Off y debe quedar así:
    <customErrors mode="Off" />
     
Al ingresar de nuevo al sitio (o simplemente pulsando F5), debemos ver un error completamente diferente, el verdadero, el que nos ha dejado sin dormir, el que hay que corregir.

Para todos aquellos que llegaron a ver este desdichado artículo, los remito al lugar que debieron haber leído primero, para conocer un poco más del tema, del directamente responsable de su existencia: Microsoft y su documentación respecto a Elemento customErrors (Esquema de configuración de ASP.NET).


3 comentarios:

7 razones para no usar Laravel en tu proyecto de PHP

En más de 40 años de experiencia como programador y director de proyectos de programación, he aprendido que cada requerimiento tiene mejores...