Tag Archive for c#

Verificando si un link existe con la .Net Framework

Un amigo necesitaba algo para recorrer una lista de links y ver si estos existian o no, como necesitaba la .Net framework decidí ayudarle y crearle un simple Extension Method que podría hacerle la vida más fácil que revisar link por link manualmente si la página existía, aquí los dejo con el código:

using System;
using Xunit;

namespace ClassLibrary2
{
    public class BrokenLinkFacts
    {
        [Fact]
        public void IsBrokenMustReturnFalse()
        {
            var url = new Uri(@"http://www.google.com");
            Assert.False(url.IsBroken());
        }

        [Fact]
        public void IsBrokenMustReturnTrue()
        {
            var url = new Uri("http://www.rioshu.com/does_not_exist");
            Assert.True(url.IsBroken());
        }

        [Fact]
        public void IsBrokenStringMustReturnFalse()
        {
            const string url = @"http://www.google.com";
            Assert.False(url.IsBroken());
        }

        [Fact]
        public void IsBrokenStringMustReturnTrue()
        {
            const string url = @"http://www.rioshu.com/does_not_exist";
            Assert.True(url.IsBroken());
        }
    }
}
using System;
using System.Net;

namespace ClassLibrary2
{
    public static class UrlExtension
    {
        public static bool IsBroken(this Uri uri)
        {
            var web_client = WebRequest.Create(uri);
            web_client.Timeout = 2000;

            try {
                web_client.GetResponse();
            } catch (WebException exception) {
                return true;
            }

            return false;
        }

        public static bool IsBroken(this string uri_string)
        {
            var uri = new Uri(uri_string);
            return IsBroken(uri);
        }
    }
}

Mapeando subclases en varios archivos de NHibernate

Creando el mapping de una legacy DB en la oficina, me topé con el mapping de herencia de NHibernate (muy efectivo por cierto). Aunque ya he mapeado herencia anteriormente en NHibernate, algo que irrita de sobremanera es el archivo gigante que se crea ante la clase base. Revisando la documentación de NHibernate me topo con el concepto de mapas modulares para clases de herencia, algo que nos resuelve los dolores de cabeza con mapeos de herencia muy grandes :D

Tomemos por ejemplo este mapping:

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="Sample"
                   namespace="Sample">
  <class name="Member" table="members">
    <id name="Username" column="username">
      <generator class="assigned" />
    </id>
    <discriminator column="type" type="Int32" />
    <property name="FirstName" column="first_name" not-null="true" />
    <property name="LastName" column="last_name" not-null="true" />
    <property name="Email" column="email" not-null="true" />
    <property name="BirthDate" column="birthdate" not-null="true" />
    <joined-subclass table="students" name="Student">
      <key column="student_id" />
            <property name="Added" />
    </joined-subclass>
  </class>
</hibernate-mapping>

(Para comprender un poco más de herencia en nhibernate usando joined-subclass recomiendohttp://www.hibernate.org/hib_docs/nhibernate/1.2/reference/en/html/inheritance.html en la documentación de NHibernate).

Bien, lo feo es que si he de mapear 5 clases heredadas debo agregar cada joined-subclass en el mismo archivo y eso me crearía archivos de mapeo poco portables y de díficil mantenimiento. Es cuando llega a salvar los archivos de mapeo modular.

En el caso anterior movemos la declaración de joined-subclass de Student a su propio archivo hbm y solo variamos agregandole el atributo “extends” indicando que clase (definida en su propio hbm) extendemos.

<?xml version="1.0" encoding="utf-8" ?>
<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"
                   assembly="Sample"
                   namespace="Sample">
  <joined-subclass table="students" name="Student"
                   extends="Member">
    <key column="student_id" />
    <property name="Added" />
  </joined-subclass>
</hibernate-mapping>

Sencillo no?

Otro día hablaremos un poco más de nuestro siempre versátil NHibernate ;)

Cambiando el tamaño de una imagen con métodos de extensión

Es común en aplicaciones web trabajar con imágenes y hacer una que otra simple operación (cambiar el tamaño de una imagen, cambiar el formato de una imagen, obtener el MimeType de una imagen, cosas como esas).

Como duplicar código es lo peor que uno puede hacer, aproveché la simempre útili ayuda de los Extension Methods para estas simples operaciones, se los comparto a todos :D

using System;
using System.Drawing;
using System.Drawing.Imaging;
using System.IO;

namespace Rioshu.Utils.Drawing
{
    public static class ImageExtensions
    {
        public static Image ToSize(this Image image, int width, int height)
        {
            var resized_image = new Bitmap(width, height);
            using (var graphics = Graphics.FromImage(resized_image)) {
                graphics.DrawImage(image, 0, 0, width, height);
            }

            return resized_image;
        }

        public static Image ToSize(this Image image, int size)
        {
            var max_side = image.Width > image.Height ? image.Width : image.Height;
            var factor = (float) size/max_side;

            var new_width = Convert.ToInt32(factor*image.Width);
            var new_height = Convert.ToInt32(factor*image.Height);

            return ToSize(image, new_width, new_height);
        }

        public static Image ToFormat(this Image image, ImageFormat format)
        {
            var memory_stream = new MemoryStream();
            image.Save(memory_stream, format);

            return new Bitmap(memory_stream);
        }

        public static byte[] GetBytes(this Image image)
        {
            var memory_stream = new MemoryStream();
            image.Save(memory_stream, image.RawFormat);
            var content = new byte[memory_stream.Length];
            memory_stream.Seek(0, SeekOrigin.Begin);
            memory_stream.Read(content, 0, content.Length);

            return content;
        }

        public static string GetMimeType(this Image image)
        {
            foreach (var codecInfo in ImageCodecInfo.GetImageDecoders()) {
                if (codecInfo.FormatID == image.RawFormat.Guid) {
                    return codecInfo.MimeType;
                }
            }
            return "image/unknown";
        }
    }
}

La forma de usarlos es sumamente fácil, basta con un simple ejemplo:

// digamos que leemos un archivo o stream que contiene una imagen
var image = Image.FromStream(file_stream).ToSize(125, 125);
// Resto de las operaciones de imagen

Espero le sea de ayuda a mas de alguien. Saludos!

Usings y Object Initializers == Problemas!

Revisando mis links diarios me topo con esta noticia del famoso Ayende (alias de Oren Eini) acerca del uso de Objects Initializers en using statements, explico un poco de que se trata:

Como ustedes recuerdan, objetos que obedecen a la Dispose Pattern, como por ejemplo los DataReaders en ADO.net, mantienen un patron de “destrucción” con instrucciones de liberación de recursos o instrucciones de destrucción del objeto, en otras palabras, que hacer cuando el objeto ya no es necesario (no implica que deterministicamente destruimos al objeto, eso es otrotema):

// Hacemos lo que queremos con el objeto repository
var repositorio = new UserRepository();
repositorio.Dispose();

Bien, de igual manera el compilador de C# 3.0 nos ofrece la opción de inicializadores de objeto, imaginemos que el objeto repositorio pueda tener un parámetro opcional con la información del “nombre” del repositorio (nuevamente un ejemplo silly):

// forma C# 2.0
var repositorio = new UserRepository();
repositorio.Name = "Mi repo";

// forma C# 3.0 con object initializers
var repositorio = new UserRepository() { Name = "Mi repo" };

Internamente el compilador agrega la siguiente línea con un setter a la propiedad, interesante no?.

Bien, como recordaran, la Disposable Pattern es tan común que hay una forma de “resumirla” o un shortcut en la framework:

using (var repositorio = new UserRepository()) {
    // Hago lo que quiera con el objeto
}

Si el objeto generara una excepción DENTRO del bloque de igual manera se correría Dispose, eso hace más segura nuestra implementación.

Bien, que tal si mezclamos ambas?:

using (var repo = new UserRepository() { Name = SimpleClass.GetName() }) {
// Blah
}
// PROBLEMA!!! lo "equivalente" generado
var repo = new UserRepository();
repo.Name = SimpleClass.GetName();
using (repo) {
// Blah
}

Aunque mi ejemplo es realmente trivial y hasta “tonto” podemos observar claramente el problema, si el inicializador “repo.Name = ’blah’” fallara, NUNCA entraríamos al using, por lo tanto no se correría Dispose(), o sea, que recursos no se liberarían como nosotros esperaramos.

Tengo entendido que esto es “by design” (realmente no se porqué), y que el compilador de Mono (el MCS) lo genera de la manera “ideal”. Esperemos que para C# 4.0 compiler esto sea resuelto, mientras tanto, eviten object initializers en declaraciones de sentencias using.

Hasta la próxima!

UPDATE:

Para contestar uno de los comentarios: si, si definimos tu "conexión" de la manera:

using (var con = new SqlConnection() { MyProperty = int.Parse("error") }) {
// Buh! nunca entro aqui! (ni corro dispose!)
}

En ese caso se genera una instancia con nombre "impronunciable" y se usa el setter, para luego entrar al bloque using. Eso involucra que cuando falle el setter de la propiedad tu objeto nunca entrará al bloque using, para evitar eso deberiamos cambiar el código para que luzca algo asi:

using(var con = new SqlConnection()) {
    con.MyProperty = int.Parse("error");
}

La última sentencia funcionará como esperamos, se creará una excepción, pero debido a que la excepción se generó dentro del bloque se correrá exitosamente el Dispose del objeto SqlConnection.