.NET

ASP.NET Bundling and Minification Gotcha #1 – Javascript bundle not rendering

ASP.NET Logo

Having used a couple of other bundling and minification libraries like Cassette and RequestReduce in the past, I started playing with the new bundling and minification features in ASP.NET 4.5. While setting up bundles is easy, there are quite a few gotchas that are not yet fully documented on the web.

This specific situation/gotcha took me a couple of hours to figure out, and I almost gave up on using Microsoft’s bundling completely.

In order to ease debugging for us developers, bundling and minification only happens if one of the following conditions are met:

1. You’re running with <compilation debug=”false”> on web.config (or without the attribute at all)
2. You force Bundle Optimizations to be ON by specifiying BundleTable.EnableOptimizations = true; on the RegisterBundles method.

When you’re running in debug mode, the files specified on bundles will not be minified or bundled, and tags will be rendered for each file in the bundle.

While that is great, the problem is the way Microsoft assumed that all developers have both development and release versions of each script that they use. As in, if you’re using jQuery, and you want to add jQuery to a bundle, Microsoft will expect you to have both the jQuery-1.8.0.js and the jQuery-1.8.0.min.js files added to your solution.

If you only have the .min.js file in your project, you configure your bundle to use that already-minified script, and you’re running in debug mode, any .min sripts will not be rendered in debug mode. What’s worse, if you only had .min.js scripts in that bundle, nothing will be rendered for it, as if it did not exist or was not configured, nada. No HTML tag for it.

Why?

Because as this StackOverflow question’s accepted answer states, there is a default ignore list that is enforced when rendering the bundle, and for debug mode, all *.intellisense.js, *-vsdoc.js, *.debug.js, *.min.js and *.min.css files are completely excluded from being rendered, because again, Microsoft assumed that you have both release and debugging versions of the scripts or stylesheets that you use in your project.

To be fair, the official tutorial on ASP.NET Bundling and Minification, does mention of some of the conventions, but it can be confusing. The post states:

“Selecting the non “.min” version for debug.”

“Selecting” implies you have choices. If a project only has release (.min.js) versions of a script, they are not added. If they had two choices, but one of the choices is not even an option in the situation, they should default to the other option, not to ignore the script. The post should have stated

“Only non .min versions are included for debug”

Their intention is good, but I believe the assumption/implementation is a bit flawed. I feel if they’re going to ignore a file that you explicitely specified in your bundle configuration, they should at least check for existance of the debug version of the script in your project before ignoring your request to add the release version to the bundle.

So, in order for your bundle to render those .min.js scripts, you have two choices.

1. Just add the debug version of the script you want to use to your project.
2. Clear the ignore list of the bundle (or just the entry you do not want ignored), although there might be side effects to that if you have other scripts of which you do have both versions.

Hope this saves someone a headache.

Bug en Subsonic 3.x al comparar instancias de objetos

He utilizado Subsonic de Rob Conery por varios años, desde sus primera version.

Es un ORM decente, hecho por un buen desarrollador. Subsonic ya no se desarrolla activamente (ahora se enfoca en Massive, su micro ORM), pero la ultima version, 3.0.0.4, sigue siendo utilizada por varios proyectos.

Hace algunas semanas desarrolle una funcionalidad nueva en un proyecto existente, que utilizaba Subsonic, y al estar probando la funcionalidad descubri un bug en Subsonic y la manera en que compara instancias de objetos de la misma clase, haciendo que siempre regrese false en una comparacion.

El codigo problema esta en el metodo Equals, generado por el template T4 de ActiveRecord de Subsonic:

public override bool Equals(object obj)
{
    if(obj.GetType()==typeof(Entity))
    {
        Entity compare=(Entity)obj;
        return compare.KeyValue()==this.KeyValue();
    }
    else
    {
        return base.Equals(obj);
    }
}

Y el metodo KeyValue hace esto:

public object KeyValue()
{
    return this.EntityId;
}

Al estar comparando dos objetos, este metodo es llamado, y si los objetos que se estan comparando son de la misma clase, ejecuta la linea

    return compare.KeyValue()==this.KeyValue();

El metodo KeyValue() simplemente regresa el valor del campo que este asignado como Id de la clase, ya sea un entero, un GUID, long, etc. El problema es que regresa el valor casteandolo a tipo object. Es decir, la siguiente comparacion regresara false, incorrectamente:

    bool testOne = (object)5 == (object)5; //this will return false

No importa que estamos comparando un valor constante, porque lo estamos casteando a ser de tipo object. La comparacion correcta seria comparar los objetos directamente (sin castearlos), o utilizando el metodo Equals de la misma clase.


    bool testTwo = 5.Equals(5); //this will return true, as we expect.

Entonces, para corregir el bug en Subsonic, se puede actualizar el template T4 de la siguiente manera:

public override bool Equals(object obj)
{
    if(obj.GetType()==typeof(<#=tbl.ClassName#>))
    {
        <#=tbl.ClassName#> compare=(<#=tbl.ClassName#>)obj;
        return compare.KeyValue().Equals(this.KeyValue());
    }
    else
    {
        return base.Equals(obj);
    }
}

Es decir, reemplazando la comparacion anterior (que usaba el operador ==) con una llamada explicita al metodo Equals de la instancia del objeto que estamos comparando.

Espero les sirva.

Como eliminar la excepcion ThreadAbortException al navegar entre paginas en ASP.NET

Llevo casi 10 años trabajando con ASP.NET y me sorprendi al aprender que cada vez que se ejecuta el comando Response.Redirect(url) en ASP.NET (para navegar hacia otra pagina), el framework lanza intencionalmente una excepcion de tipo ThreadAbortException, con el unico objetivo de terminar absolutamente la ejecucion del request actual.

Como mencione, esto es intencional por parte del framework, y el articulo “Correct use of System.Web.HttpResponse.Redirect” de Thomas Marquardt explica las razones de este diseño.

Para observar esto, solo se necesita correr una aplicacion de ASP.NET en Debug Mode, y ejecutar una linea de Response.Redirect(“Default.aspx”), y observar la ventana de Output en Visual Studio; se vera lo siguiente:

A first chance exception of type ‘System.Threading.ThreadAbortException’ occurred in mscorlib.dll

An exception of type ‘System.Threading.ThreadAbortException’ occurred in mscorlib.dll but was not handled in user code 

Como la mayoria de los desarrolladores debe saber, esto es un problema porque uno de los principales lineamientos de performance en .NET es “No utilizar Exceptions para controlar el flujo de la aplicacion“. Si esto sucede en una aplicacion web con mucho trafico, el lanzar exceptions cada vez que un usuario navega de una pagina a otra, eventualmente va a afectar el desempeño de la aplicacion.

En fin, la solucion para esto es sencilla, pero hay un detalle importante que hay que tomar en cuenta. Como el articulo de Thomas M. indica, se debe de utilizar el siguiente codigo:

Response.Redirect("Target.aspx", false);

HttpContext.Current.ApplicationInstance.CompleteRequest();

Es decir, utilizamos el overload de Response.Redirect pasando false al parametro de endResponse(para evitar que el .NET framework haga la llamada interna a Response.End(), y al final indicamos que deseamos completar/finalizar el request.

El detalle importante que hay que considerar si deseamos utilizar esta manera de redireccionar para evitar la excepcion es que antes, la llamada interna a Response.End() hacia que cualquier codigo que estuviera despues de la llamada original a Response.Redirect() ya no se ejecute, y esto es algo a lo que inconscientemente muchos desarrolladores nos acostumbramos. No es nada raro ver codigo de este tipo en aplicaciones de ASP.NET:


if (!User.HasAccess()) Response.Redirect("GetOut.aspx");

SinceUserHasAccessDoThis();

Si lo hacemos de la manera nueva, pasando el overload con false, cualquier codigo en el metodo que este despues del Response.Redirect si se ejecutara.

Esto es porque era la llamada interna a Response.End() (que ahora estamos evitando) que terminaba la ejecucion del codigo. Como ahora estamos evitando esa llamada, la funcion SinceUserHasAccessDoThis() si se ejecutaria, a pesar de que el usuario no tuviera el acceso que se verifica en el metodo HasAccess().

Aparte de lograr evitar esas excepciones, aprendi que tambien es incorrecto utilizar Response.Redirect para controlar el flujo de la aplicacion, y al menos yo lo hacia inconscientemente. Si se desea evitar esas Exceptions y no se tiene el tiempo para hacer un refactor del codigo para estructurarlo correctamente, se puede arreglar utilizando un return; despues del Response.Redirect, de esta manera:


if (!User.HasAccess())
{
    Response.Redirect("GetOut.aspx", false);
    HttpContext.Current.ApplicationInstance.CompleteRequest();
    return;
}

SinceUserHasAccessDoThis();

Paginas de referencia

  1. Response.Redirect causes System.Threading.ThreadAbortException
  2. Correct use of System.Web.HttpResponse.Redirect
  3. Microsoft Support: PRB: ThreadAbortException Occurs If You Use Response.End, Response.Redirect, or Server.Transfer
  4. HttpApplication.CompleteRequest Method
  5. Is Response.End() considered harmful?
  6. Rick Strahl – Ending a Response without Response.End() Exceptions?

Espero les sirva.

Como determinar el tamaño de los objetos en Session State en una aplicacion de ASP.NET

En el proyecto en el que estoy asignado actualmente, trabajamos en una aplicacion financiera (ASP.NET WebForms) muy grande. Utilizada en varios paises por miles de usuarios, siempre estamos buscando optimizar la aplicacion lo mas que podamos.

El caso de este post en especifico, es que notamos que habia muchos objetos almacenados en Session State y teniamos curiosidad de saber el tamaño que esos objetos estaban ocupando, para saber si era un area que debiamos optimizar. En la actualidad, la memoria RAM es de los componentes mas baratos y una de las maneras mas faciles de mejorar el desempeño de una aplicacion, pero si acaso una empresa, aplicacion o equipo esta limitado en presupuesto, igual es un area que se puede mejorar.

Como siempre, en StackOverflow.com ya habia alguien que habia tenido la misma duda que nosotros, y pudimos obtener un metodo que serializa a disco los contenidos de la sesion para poder medir su tamaño. Este es el metodo:

protected void PrintSessionSize()
{
 long totalSessionBytes = 0;
 var b = new System.Runtime.Serialization.Formatters.Binary.BinaryFormatter();
 System.IO.MemoryStream m;

 foreach (var obj in HttpContext.Current.Session)
 {
     m = new System.IO.MemoryStream();
     b.Serialize(m, obj);
     totalSessionBytes += m.Length;
 }
}

Espero que les sirva.

1 2 3 7  Scroll to top