Desarrollo de Software

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 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.

Que significa “Inconsistent line endings” en Visual Studio

Despues de muchos dias de que este dialogo me saliera en varias clases de C# en un proyecto en el que estoy, decidi averiguar que significaba “Inconsistent Line Endings” y que planeaba hacer Visual Studio al normalizar los line endings.

Como siempre, algun desarrollador brillante ya habria escrito sobre este problema: Jeff Atwood escribió The Great New Line Schism.

Resulta que es algo tan sencillo como que diferentes sistemas operativos utilizan diferentes caracteres para indicar el final de una linea de texto. Y como los caracteres obviamente son invisibles, no nos damos cuenta del problema hasta que abrimos ese archivo en otro sistema operativo. En mi caso, la mezcla se dio al haber pegado una linea de codigo (Un using statement…nadie deberia hacer copy/paste de codigo) en varias de mis clases. Otra posible razon es que si es un archivo compartido, las personas que estan editando el archivo esten usando diferentes sistemas operativos para abrir el archivo.

Esta animacion (tomada prestada del mismo articulo de Atwood) ilustra el problema:

Al momento de detectar que hay caracteres de newline mezclados, Visual Studio ofrece normalizarlos al estilo de Windows (CR + LF).

Asi es que desde ahora, pueden seleccionar Yes en ese dialogo…

Como verificar con C# si un archivo existe en un servidor remoto, sin descargar el archivo

.NET logo

Con este codigo de C# se puede verificar si un archivo existe en un servidor remoto, sin bajarlo.

var request = WebRequest.Create(new Uri("http://www.site.com/file1.zip"));

request.Method = "HEAD";

try
{
	var response = request.GetResponse();
	Console.WriteLine("{0} - {1}", response.ContentLength, response.ContentType);
}
catch (WebException ex)
{
	var resp = (HttpWebResponse) ex.Response;

	if (resp.StatusCode == HttpStatusCode.NotFound)
	{
		Console.WriteLine("File does not exist");
	}

}

La diferencia es el uso del metodo HEAD en lugar de POST o GET. El metodo HEAD regresa exactamente los mismos Headers que un request tipo GET, con la excepcion de que no transfiere el message-body, o en este caso, el contenido del archivo en bytes. Este codigo funciona para verificar la existencia de archivos fisicos, o URLs virtuales (ya que no siempre un URL corresponde a un archivo fisico).

Una vez que obtenemos una respuesta, podemos verificar varias propiedades del archivo, como el tamaño (ContentLength) o el tipo (ContentType). Si el archivo no existe, el Framework va a lanzar una WebException, de la cual tomamos la propiedad Response y le podemos hacer un cast al tipo HttpWebResponse, para poder verificar el error especifico HTTP que el servidor arrojó. Si el codigo es 404, significa que el archivo no existe.

Espero les sirva.

1 2 3 4  Scroll to top