Archivo de la etiqueta: asp.net

Utilizar AsyncPostBackTrigger o Update

Cuando utilizamos un UpdatePanel en Asp.Net WebForms a veces no tenemos en cuenta el uso final al que va destinado. Es decir, en ocasiones se hacen llamadas al servidor que no requieren un refresco del UpdatePanel con lo que no tiene sentido actualizarlo.

Entendiendo el UpdatePanel

Existe una propiedad fundamental para configurar el UdpatePanel y este es el UpdateMode. Puede tener 2 valores: Allways y Conditional.

Si establecemos este valor en Allways, todas las llamadas al servidor de los controles que produzcan un postback harán refrescar el panel. Esta es una opción muy rápida, que además viene por defecto, pero en mi opinión no nos ayuda nada a la hora de aprovechar al máximo los beneficios de AJAX y el UpdatePanel.

Estableciendo el valor UpdateMode en Conditional, deberemos preocuparnos nosotros de indicar qué controles realizarán el update en el panel o bien indicarle en nuestro código cuándo debe actualizarse.

Establecer los controles en la sección Triggers para indicar cuales de ellos producirán un update del panel puede parecer una buena opción, desde luego no está mal, pero ¿por qué deberíamos hacerlo si podemos indicarlo en el código mediante el método Update() del UpdatePanel?

La ventaja de utilizar el método Update() frente por ejemplo AsyncPostBackTriggers es que tenemos controlado en todo momento cuando se debe actualizar el UpdatePanel. Si, por ejemplo, tenemos un método en el servidor que responde a un click de un botón y dentro de este método tenemos condicionales que harán que el resultado sea o no visible para el usuario podremos indicar nosotros mismos cuando una acción alterará los datos visibles en pantalla mediante el método Update().

 

Utilizar AsyncPostBackTrigger o Update
4.5 (90%) 2 votes

Realizar tareas programadas en una aplicación ASP.Net

Desarrollo y programación .net

Por circunstancias de la vida me he encontrado últimamente con varios proyectos realizados en ASP.Net que requieren realizar tareas programadas que se ejecuten en un momento concreto del día independientemente si existe o no usuarios conectados.

Como suele ocurrir existen muchas maneras de abordar esta funcionalidad:

  • Mediante Servicios Windows, siempre que tengamos total control de nuestro servidor y el entorno para realizar la tarea en cuestión (Base de Datos, acceso al sistema de ficheros, etc.)
  • Mediante WCF. También sería necesario acceso total a IIS y a su configuración.
  • Mediante programación dentro de la misma aplicación ASP.Net.

Seguro que existe alguna otra pero mi objetivo primordial en todos estos proyectos que debía realizar era optimizar los tiempos mantenimiento, para ello creo que la última solución resultaba la mejor en este caso ya que solo tendría que dedicarme a modificar un único proyecto: la aplicación ASP.Net. De otro modo tendría que instalar el servicio windows o configurar el proyecto WCF dentro del IIS.

Así que me puse a investigar por la web cuales eran las mejores prácticas de cómo realizar una tarea programada en background dentro de ASP.Net. Encontré una solución que me parecía muy clara y que muchos reportaban como buena. Su funcionamiento requería del uso de la caché de la aplicación web y el método application_start dentro del global.asax.

Su uso consistía en añadir un objeto a la cache en el contexto de ejecución para que cuando dicha cache expirara utilizara el evento para ejecutar de nuevo la tarea. La palabra clave para este método es CacheItemRemovedCallback… pero os anticipo que yo NO LO UTILIZARÉ MÁS.

No voy a adentrar en los motivos de rehusar finalmente este método pero os puedo asegurar que da problemas, incluso cuando establecemos el tiempo de inactividad a 0 dentro del pool de aplicaciones del IIS, que en principio parecía que podía ser una de las soluciones.

Investigando un poco más pude dar con un componente muy interesante: Quartz.

Su uso es muy sencillo y parece ser que existe un componente homónimo en Java.

Quartz tiene una Interfaz denominada IJob que únicamente expone un método llamado Execute(). Si deseas hacer una tarea a nivel de aplicación únicamente debes llamar JobScheduler.Start() dentro de Application_Start() del Global.asax.

using Quartz;
using Quartz.Impl;
using System;
 
namespace ScheduledTaskExample.ScheduledTasks
{
    public class JobScheduler
    {
        public static void Start()
        {
            IScheduler scheduler = StdSchedulerFactory.GetDefaultScheduler();
            scheduler.Start();
 
            IJobDetail job = JobBuilder.Create<MyJob>().Build();
 
            ITrigger trigger = TriggerBuilder.Create()
                .WithDailyTimeIntervalSchedule
                  (s =>
                     s.WithIntervalInHours(24)
                    .OnEveryDay()
                    .StartingDailyAt(TimeOfDay.HourAndMinuteOfDay(0, 0))
                  )
                .Build();
 
            scheduler.ScheduleJob(job, trigger);
        }
    }
}
Realizar tareas programadas en una aplicación ASP.Net
4 (80%) 1 vote

Optimizar cache en IIS

En este post aprenderemos a optimizar cache en IIS editando el web.config.

Si tu servidor de alojamiento web es IIS puedes mejorar la velocidad de tu sitio estableciendo el tiempo de la caché insertando dentro de <system.webServer> del archivo web.config de la raíz de tu aplicación web:

<staticContent>
<clientCache cacheControlMode=”UseMaxAge” cacheControlMaxAge=”7.00:00:00″ />
</staticContent>

Donde cacheControlMode puede tomar los valores:

  • “NoControl”: no se establece un tipo de caché para el sitio, con lo que tomará los valores globales de configuración heredados.
  • “DisableCache”: caché deshabilitada para el sitio.
  • UseMaxAge: se especifica una edad de expiración de la caché en el parámetro cacheControlMaxAge en días, horas, minutos y segundos (d.hh:mm:ss)
  • UserExpires: indica la fecha exacta de expiración de la caché.
Optimizar cache en IIS
Valora este artículo

Error de validación de viewstate MAC

En el supuesto de que instales tu aplicación web en una granja de servidores debes tener en cuenta que es posible que la validación del viewstate no se comporte correctamente. Como sabemos para un programador esto es un problema porque son errores que no se producen en nuestro equipo local de desarrollo sino que es en el despliegue.

El error

El error en cuestión es el siguiente:

Validation of viewstate MAC failed. If this application is hosted by a Web Farm or cluster, ensure that <machineKey>….

ViewState MAC Farm

¿Por qué este error?

Como sabemos en asp.net existe el concepto del viewstate que permite guardar el estado de ciertos controles y partes de la página para ser reutilizados después de un postback. Esto que a priori es una ventaja implica el inconveniente de que un usuario malintencionado envíe una carga _VIEWSTATE y engañe a la aplicación y realice una acción que no se debería realizar.

Para evitar este tipo de ataque el campo _VIEWSTATE se protege codificándolo con un código de autenticación de mensajes (MAC). ASP.Net valida el MAC que se envía con la  carga cuando se produce un postback, si no coincide se produce un error en la validación del viewstate.

La clave que se utiliza para calcular el MAC está en el elemento machineKey de la aplicación en el archivo web.config.

Una de las causas más comunes que provocan este error es que nuestra aplicación está en una granja de servidores, en este caso cada uno de los servidores generará una machineKey para nuestra app y entonces ninguno acordará cual aplicar.

Solución

La mejor solución y más sencilla es aplicar una machineKey explícitamente en nuestro web.config. De esta manera cualquier servidor que pretenda ejecutar nuestra aplicación utilizará de manera obligada la clave que le establezcamos en este fichero.

¿Cómo generamos nuestra clave machinekey?

Para generarlo tenemos varias maneras pero yo recomiendo nunca utilizar sitios web donde se generan automáticamente ya que no sabemos si estas claves se han generado de forma segura o son guardadas para posibles usos malintencionados, buff ya sé que suena muy rebuscado pero no nos podemos fiar, solo debemos usar las claves generadas por nosotros mismos.

En este link podemos ver varias maneras para crear el machine.config.

¿En qué sección del web.config editamos nuestra machinekey?

El elemento <machineKey> solo es válido en el archivo Web.config en la raíz de la aplicación y no es válido en el nivel de subcarpeta (location).

<configuration>
  <system.web>
    <machineKey ... />
  </system.web>
</configuration>

 

Error de validación de viewstate MAC
5 (100%) 1 vote

Problema con edmx al publicar en Azure

Espero que no tengas el siguiente problema con edmx al publicar en Azure.

Primero expongo la situación en la que me encontré:

Empecé a desarrollar un proyecto con Visual Studio 2013 en el que partía de una base de datos SQLServer Azure ya creada. Añadí un elemento de edmx para crearme las entidades de la base de datos así como las vistas y procedimientos almacenados.

En mi equipo local conectaba con esta base de datos y el contexto de Entity Framework también funcionaba correctamente ya que conseguí agregar el origen de datos de una tabla a mi GridView.

Pues bien, cuando terminé mi desarrollo y me decidí por publicarlo en Azure al llegar a cualquier pantalla donde necesitaba acceder a los datos me daba el siguiente error:

…SQLException Invalid Object Name “dbo.NombreTabla”…

Lo que aparentemente dice este error es que no existe la tabla en la base de datos a la cual me conectaba. Esto me parecía increíble porque ni siquiera estaba trabajando con la base de datos local sino que en el momento de la programación atacaba directamente a la base de datos en Azure y… funcionaba y seguí funcionando, con lo que la cadena de conexión debería de ser la misma.

Después de darle muchas vueltas observé que aparte de publicar mediante la opción “Web Deploy” existe la opción de publicar mediante “ftp”. Decidí publicar en azure mediante ftp y finalmente conseguí que funcionara.

Aún no sé porque el método “Web Deploy” no funcionaba correctamente pero si alguien sabe o intuye por qué por favor que nos lo comente.

 

 

Problema con edmx al publicar en Azure
Valora este artículo

Cómo localizar identity de asp net

En esta entrada haremos una pequeña explicación de cómo localizar identity de asp net.

Cuando utilizamos esta nueva característica de asp.net nos daremos cuenta que los mensajes de error propios de la validación tanto de la entidad como de negocio aparecen siempre en inglés.

La solución más sencilla para poder utilizar otras traducciones de identity será la instalación de un paquete a través de la consola de administración de paquetes con el siguiente comando:

install-package Microsoft.AspNet.Identity.Core.xx

Las últimas letras indican el idioma que queramos instalar, por ejemplo para español sería es.

install-package Microsoft.AspNet.Identity.Core.es

Una vez instalado los errores aparecerán (en este caso concreto) en castellano.

Cómo localizar identity de asp net
Valora este artículo

Envío de Mails con ELMAH

El envío de mails con ELMAH es una de las muchas virtudes que tiene este sistema de control de errores. En este post intentaré explicar cómo se configura.

Nota: partiremos de una instalación correcta de ELMAH. Si no sabes instalar y configurar ELMAH te recomiendo este post.

Paso 1: configurar una cuenta de correo en el web.config.

En realidad este paso no es propio de ELMAH, en el web.config se puede establecer muchos parámetros que puedes o no utilizar cuando desarrolles tus aplicaciones o software.

Para añadir una cuenta de correo deberemos abrir una sección llamada <system.net> dentro de la raíz <configuration> del web.config.

Como una imagen vale más que mil palabras aquí está la configuración completa:

Envio de mails con ELMAH

Como vemos establecemos el servidor  smtp, el puerto, el nombre de usuario y la contraseña de la cuenta.

Paso 2. Indicar a ELMAH datos del envío de correo.

El segundo paso sí que tiene lugar en la sección propia de ELMAH dentro del web.config. De nuevo podemos en una imagen como configurarlo:

Configurar envio mail con elmah

En la imagen vemos que estableceremos el campo “from” (dirección remitente del correo), el campo “to” (destinatario) y el asunto “subject”.

Si nos fijamos el asunto tiene el código {0} que indica que en esa posición se sustituirá el mensaje del error de tal modo que el destinatario podrá ver de una manera rápida en que consiste el problema.

Envío de Mails con ELMAH
Valora este artículo

Modificar url de acceso elmah axd

Por seguridad es mejor cambiar la url donde se accederá a los errores de aplicación de ELMAH. Como sabemos en el momento de la instalación la url de acceso es la siguiente:

http://”misitio.com”/elmah.axd

Si queremos cualquier otra como por ejemplo:

http://”misitio.com”/mis_errores.axd

Deberemos reemplazar en el web.config todas las ocurrencias que encontremos de “elmah.axd” por “mis_errores.axd”

Modificar url de acceso elmah axd
Valora este artículo

Acceso remoto en ELMAH

El acceso remoto en ELMAH por defecto está desactivado.

Esto quiere decir que solo podremos acceder a nuestra pantalla de monitorización si accedemos desde la misma IP donde está el hosting de nuestra aplicación.

Dependiendo si queremos acceder únicamente desde nuestro equipo servidor o desde cualquier equipo tenemos la posibilidad de configurarlo a través del web.config.

Dentro de la sección de configuración <elmah> existe una etiqueta <security> donde su propiedad “allowremoteaccess” nos permitirá activar o desactivar el acceso remoto.

acceso remoto elmah

 

Acceso remoto en ELMAH
Valora este artículo

Instalar y configurar ELMAH

Como todos sabemos el trabajo de un programador no es perfecto y por eso, haciendo caso al refrán,  es mejor prevenir que curar.  Un buen desarrollador de software tendrá en cuenta crear un log para monitorizar aquellos errores de programación y de cualquier otro tipo que puedan suceder en la aplicacíón que se desarrolla.

Al respecto el programador tiene varias opciones:

  • Crearse por sí mismo un sistema de control de errores dentro de su aplicación. Si es hábil podrá migrar este sistema a futuros desarrollos.
  • Utilizar librerías ya implementadas que cubren la funcionalidad de control de errores.

En mi caso yo recomiendo ELMAH (Error Logging Modules and Handlers) que permite crear un sistema automático de guardado de errores y además crear la infraestructura (tablas y procedimientos en base de datos y librerías .Net) para utilizarlas como servicio de logging.

Este post intentará explicar cómo instalar y configurar ELMAH para una aplicación o sitio web en asp.net.

Paso 1. Descargar las librerías de ELMAH.

El primer paso que deberás hacer es descargarte las librerías de ELMAH en tu sitio web asp.net. Esto lo puedes hacer manualmente (en este enlace) o mediante el administrador de paquetes NuGet de Visual Studio (Menú Tools – Library Package Manager – Manage NuGet Packages for Solution…)

Instalar y configurar ELMAH

En la ventana emergente buscaremos en nuget.org (Online) con la palabra clave ELMAH y lo instalaremos en nuestra aplicación Web.

Una vez instalado veremos que nos ha referenciado algunas librerías nuevas y nos habrá modificado el web.config.

Paso 2. Ejecutar el script de la base de datos.

ELMAH puede utilizar una base de datos sqlserver para guardar los errores que se van generando. El siguiente paso será crear la estructura de la base de datos a través de un script que podremos descargar aquí.

Paso 3. Utilizar la monitorización de errores.

En este punto ya podremos ver una de las ventajas de ELMAH. Utilizaremos la url http://”misitio.com”/elmah.axd para monitorizar los errores por pantalla.

Por ejemplo,

si lanzamos una excepción manualmente en nuestro código…

ELMAH Excepción manual

lo ejecutamos y después de lanzado el error vamos a la url http://”misitio.com”/elmah.axd veremos una pantalla donde aparece lo siguiente:

Error monitorización ELMAH

Es útil, pero en este punto el error no se ha guardado en la base de datos, de hecho si no te interesa guardarlo en un almacenamiento persistente podrás saltarte el paso 2 y los siguientes.

Paso 4. Configurar la base de datos.

Para enlazar ELMAH con la base de datos es necesario indicarle cual es la cadena de conexión. Para ello deberemos ir al web.config y añadir la cadena de conexión dentro de la sección que define la etiqueta <elmah>

ELMAH cadena de conexión

Si nos fijamos en la etiqueta errorLog, se le está indicando que para el tipo de módulo sqlerrorlog utilice la cadena de conexión con el nombre “DefaultConnection” que la hemos definido previamente en el web.config.

Si la cadena de conexión es correcta los errores se empezarán a guardar en este punto en la base de datos.

En futuros posts veremos algunas configuraciones extra que podemos utilizar con ELMAH como son el envío de mails, seguridad, etc…

 

Instalar y configurar ELMAH
Valora este artículo