Te deseamos lo mejor! Que los cumplas muy feliz!!!

Saludos!

En el artículo previo (Actualizador 1era Parte) llegamos a definir la estructura iba a tener nuestro archivo de actualizaciones, ahora solo nos falta descargar esa información, parsearla y hacer algo útil con ella.

Recuerden que el formato a utilizar en dicho archivo será el siguiente:

ruta relativa y nombre de archivo : versión

donde la primer parte antes de caracter : es la ruta relativa tanto remota como local; y la segunda es la última versión disponible.
Veamoslo con un ejemplo que va a ser más fácil de entender. Suponiendo que mi programa consiste de los siguientes archivos:

C:\Mi Programa\EjecutablePrincipal.exe
C:\Mi Programa\una_carpeta\OtroArchivo.dll
C:\Mi Programa\otro path con espacio\Lala.dll

En el servidor de actualizaciones tendríamos:

http://miservidor.algo/actualizaciones.txt
http://miservidor.algo/EjecutablePrincipal.exe
http://miservidor.algo/una_carpeta/OtroArchivo.dll
http://miservidor.algo/otro path con espacio/Lala.dll

Procesando la información

Ahora veremos como podemos obtener la información que necesitamos de ese archivo:

private const char SEPARADOR_VERSION = ':';

private static Dictionary<string, string> ObtenerVersionesOnline(string ServidorActualizaciones)
{
    Dictionary<string, string> listadoArchivos = new Dictionary<string, string>();
    WebClient clienteWeb = new WebClient();
    string actualizacionesEnCrudo;
    string[] actualizacionesPorLinea, informacionPorFila;

    try
    {
        actualizacionesEnCrudo = clienteWeb.DownloadString(ServidorActualizaciones);
        actualizacionesPorLinea = actualizacionesEnCrudo.Split(Convert.ToChar("\n"));

        foreach (var actualizacion in actualizacionesPorLinea)
        {
            string infoRuta, infoVersion;
            informacionPorFila = actualizacion.Split(SEPARADOR_VERSION);
            infoRuta = informacionPorFila[0].Trim();
            infoVersion = informacionPorFila[1].Trim();

            if (listadoArchivos.ContainsKey(infoRuta))
                continue;

            listadoArchivos.Add(infoRuta, infoVersion);
        }
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message, "¡Ocurrió un error al comprobar version online!", MessageBoxButtons.OK, MessageBoxIcon.Error);
    }
    finally
    {
        clienteWeb.Dispose();
    }

    return listadoArchivos;
}

Como verán, el código es bastante simple: descargamos el archivo de texto con la información de las actualizaciones (en nuestro ejemplo sería http://miservidor.algo/actualizaciones.txt), lo desglosamos linea por linea, y luego a cada una la dividimos mediante el separador que habíamos elegido previamente, en éste caso fue el caracter dos puntos. De esta forma tenemos por un lado la ruta relativa (incluyendo el nombre del archivo) y por el otro el número de versión, claro, esto por cada línea. Guardamos esa información en una lista del tipo Dictionary y listo el pollo, pelada la gallina.

El siguiente paso sería utilizar esa información para compararla con las versiones locales de los archivos equivalentes.

public static bool ComprobarActualizaciones(string ServidorActualizaciones)
{
    Dictionary<string, string> listadoArchivos = ObtenerVersionesOnline(ServidorActualizaciones);

    try
    {
        foreach (var archivo in listadoArchivos)
        {
            string rutaAbsoluta = Path.Combine(Application.StartupPath, archivo.Key);

            if (File.Exists(rutaAbsoluta))
            {
                if (archivo.Value != "?")
                {
                    Version versionLocal = new Version(FileVersionInfo.GetVersionInfo(rutaAbsoluta).FileVersion);
                    Version versionRemota = new Version(archivo.Value);

                    // De esta forma podemos volver a una versión anterior en caso que encontremos
                    // algun problema importante en un actualización (luego de publicarla)
                    if (versionLocal != versionRemota)
                        return true;
                }
            }
            else
            {
                return true;
            }
        }

        return false;
    }
    catch (Exception ex)
    {
        MessageBox.Show(ex.Message, "¡Ocurrió un error al comprobar actualizaciones!", MessageBoxButtons.OK, MessageBoxIcon.Error);
        return false;
    }
}

Lo que hacemos con éste método es recorrer la lista de actualizaciones (que obtuvimos online), tratamos de encontrar el archivo local correspondiente para cada uno de ellos y comparamos la versiones, por supuesto, solo en el caso de que exista localmente. Realmente no hace falta verificar todos y cada uno de ellos, con que encontremos uno solo desactualizado ya podremos podremos devolver un valor verdadero, que implica que existe al menos una actualización.

Vale la pena notar que en vez de:

if (versionLocal != versionRemota)
    return true;

podríamos haber usado:

if (versionLocal < versionRemota)
    return true;

No lo he hecho así por una simple razón. Me ha pasado que al publicar una actualización había algo realmente mal en alguna dll incluída, algo que cambie y no me percate que lo había roto hasta que un usuario me avisa. En estos casos prefiero volver atrás una versión para esa librería particular, simplemente modificando el archivo de texto de las actualizaciones, que tener que recompilar la dll asignándole una versión superior.

Otra cosa a tener en cuenta: es posible que en algún momento, necesitemos agregar archivos que no puedan ser versionados, al menos no como .Net lo entiende, por ejemplo, una imagen o icono. En este caso, en vez de asignar una versión en la entrada correspondiente en el archivo de texto de actualizaciones, usaremos un signo de interrogación ?. De esta forma, lo único que tendremos que verificar es que el archivo local exista, sino, se considera que hace falta una actualización (lo que va a implicar una simple descarga del archivo faltante).

Continuará …

Levante la mano aquel que todavía no se cansó de ese fondo blanco con letras negras y colores apagados con el que Visual Studio nos tiene acostumbrados desde tiempos inmemoriales. O si sos uno de esos que ya no aguanta más tener los ojos en compota cada vez que te quedas hasta tarde programando, donde la única fuente de luz es la brillante pantalla de tu notebook o desktop; o si simplemente mirabas Pimp My Ride y te gusta llevarlo a cada extremo de tu vida, hoy tengo la solución para ustedes, y no involucra ningún ¡llame ya!.

Ragnarok Grey

Por si todavía no entendieron de que va la mano les cuento: Visual Studio permite cambiar los esquemas de colores por algo más alegre o personalizado. Si son medio vagos, como yo, y no quieren hacer su propio esquema, no hay nada de que preocuparse, hay varios pupulando la red de redes. Personalmente me gusta mucho Ragnarok Grey con la fuente Monaco 9pt.

Estos esquemas y otros más pueden encontrarlos en el blog de Tomas Restrepo y en el de Scott Hanselman. Hay versiones tanto para VS2005 como VS2008.

Buenas,

Esta es la primera parte de una serie de artículos en los que voy a mostrarles como hacer su propio Actualizador para utilizar en sus programas. Todavía no he decidido de cuantas partes va a constar, porque en realidad no he planificado nada, así que si después terminan siendo solo dos, ¡quedan avisados de antemano!.

Comencemos

Por lo general, siempre que creamos un programa y lo liberamos al público, vemos al (poco) tiempo la necesidad de hacerle algunos retoques ya sea por la aparición de bugs (si, si, aparecen de la nada, no es que estaban y los pasamos por alto, jajaja) que nos reportan nuestros usuarios o porque queremos agregarle nuevas funcionalidades. Sea por lo que sea, una parte importante para mantener un software estable es la capacidad del mismo para informar la existencia de nuevas versiones o mejor aún, auto actualizarse simplificándole la vida al usuario.

Como ya habrán visto en gran variedad de programas, hay distintas formas de manejar el tema de actualizaciones. Hay que saber poner en la balanza que es lo que queremos: facilitarnos la vida nosotros, como desarrolladores, o simplificarle la vida a nuestros usuarios.

En un extremo, podríamos solamente comprobar un archivo de texto online con la referencia a la última versión. Ese número lo comparamos con el assembly local y en caso de ser diferente redirigimos al usuario a la página de descarga para que él mismo se encargue de todo el proceso (o le preguntamos mejor si quiere ir allí). Como verán, esto es muy simple de implementar, sin embargo, lo más probable es que terminemos molestando al usuario.

Por otro lado también he visto programas donde lo que se hace luego de comprobar la versión online, es solicitar permiso al usuario para descargar el nuevo instalador, es decir, la versión actualizada, dentro del mismo programa. Cuando finaliza la descarga se cierra el programa principal, se ejecuta el instalador y listo. Sin embargo hay un pequeño problema en este escenario, ¿qué pasa si el usuario no tiene permisos suficientes para instalar un programa?. También podríamos decir que no es lo mejor cuando queremos que nuestro programa sea portable, aunque en este caso hay algunos work-around para hacer un falso instalador que no escriba en el registro de Windows.

Si bien existen algunas soluciones ya integradas en .Net y de simple aplicación con Visual Studio, como ser Click Once, hay veces que requerimos de algo más personalizado y que se ajuste mejor a nuestras necesidades. Por este motivo es que he decidido mostrarles la solución que encontré yo para uno de mis proyectos, con esto quiero decir que no lo tomen como una solución universal, cada caso requiere un detallado análisis para poder evaluar cuál se ajusta más.

Para empezar vamos a necesitar dejar en claro que es lo que hace o debería hacer un Actualizador:

• Comparar versiones locales de archivos con algún repositorio remoto, y en caso de hacer falta descargar actualizaciones.
• Armar un listado de los archivos a medida que se van reemplazando para hacer un rollback en el caso que algo salga mal.
• Ser capaz no solo de actualizar otros programas, sino también, de actualizarse a si mismo.

Esos son los puntos básicos y necesarios sobre los cuales nos vamos a poner a trabajar.

Planteando la estructura

Nuestro programa va a contar con tres funciones principales:

1. Comprobar actualizaciones
2. Descargar actualizaciones
3. Limpiar restos del proceso

Más adelante pasaré a detallar un poco más cada uno de ellos, por el momento todavía falta definir como se van a almacenar las versiones en el servidor remoto.

La forma más fácil sería definir un archivo donde vamos a detallar la ruta relativa de cada componente dentro de la carpeta principal de nuestro programa y la versión online.

Por ejemplo:

EjecutablePrincipal.exe - Versión online: 2.0.0.1
una_carpeta\OtroArchivo.dll - Versión online: 2.0.0.2
otro path con espacio\Lala.dll - Versión online: 1.3.0.0

Como verán, ésta puede no ser la mejor forma de hacerlo, primero porque ¿que pasaría si la ruta de acceso contiene el caracter - (guión medio)?: no podríamos separar fácilmente la versión de ella. ¿Lo ven?, entonces podríamos mejorar un poco esto. Pensemos en los caracteres inválidos para la ruta de acceso, así podemos tomar uno y tener la certeza de que no nos va a afectar al intentar separar ambas partes.

Como sabrán, o posiblemente no, el caracter : (dos puntos) no es válido para nombres de archivo, por lo tanto, no va a existir en una ruta relativa. ¡Cuidado acá!, si ustedes desean mejorar este programa y utilizar rutas absolutas, dicho caracter puede aparecer luego de la letra de la unidad.

Pueden ver una lista de caracteres no válidos al intentar renombrar un archivo agregándole :.

Caracteres no válidos

Como se puede apreciar, el caracter | también lo podríamos utilizar.

Bueno, no nos vayamos por las ramas que después nos va a salir a perseguir Tarzán … estábamos buscando una forma de mejorar la estructura inicial que propuse para el archivo de actualización.

¿Qué les parece el siguiente?

EjecutablePrincipal.exe        : 2.0.0.1
una_carpeta\OtroArchivo.dll    : 2.0.0.2
otro path con espacio\Lala.dll : 1.3.0.0

Como verán, ahora no solo es más fácil identificar los archivos y rutas, sino también comparar las versiones, e incluso terminamos con un texto más fácil de parsear. Se habrán dado cuenta que estoy usando texto simple por comodidad y para que les resulte fácil a los que recién empiezan, pero si lo desean, podrían extender esto para utilizar XML, JSON, o algún otro formato que sea de su agrado.

También es bueno notar que hay infinitas formas de darle un formato a este archivo, incluso podrían usar un separador compuesto de múltiples caracteres, pero recuerden prestar especial atención para no generar algún conflicto con los posibles nombres de archivos y rutas de acceso.

EjecutablePrincipal.exe        |:==:| 2.0.0.1
una_carpeta\OtroArchivo.dll    |:==:| 2.0.0.2
otro path con espacio\Lala.dll |:==:| 1.3.0.0

Se podrían estar preguntando por qué es necesario especificar la versión remota, si en definitiva se puede consultar una vez descargado el archivo mediante Reflection; bien, ahí radica el problema, primero deberemos descargar el o los archivos. Si nos detenemos un momento a pensar esto, puede ser que no todos nuestros usuarios cuenten con una conexión de banda ancha, con lo cual hacerle descargar todo el paquete que conforma la actualización y luego preguntarle si la quiere sonaría, cuando menos, ridículo. En el caso que no desee aceptarla, los habremos descargado inútilmente generando una carga innecesaria en nuestro servidor de actualizaciones y además, consumiendo recursos que podrían llegar a ser limitados o escasos.

Continúa en Actualizador (2da Parte)

Buenas amigos! Hoy vamos a hablar un poquito sobre el uso de interfaces. ¿Qué son? ¿Para qué sirven? ¿Cómo usarlas? Éstas son algunas de las interrogantes que intentaremos responder.

¿Qué son?

Las interfaces son un conjunto de miembros abstractos (es decir, que no proveen una implementación por defecto) definidos bajo un nombre. Dichos miembros pueden ser por ejemplo métodos.

¿Para qué sirven?

Las interfaces expresan un protocolo o un comportamiento que las clases o estructuras deben implementar. Podemos pensarlo como un contrato que aceptan las clases si quieren implementar ese protocolo.

¿Cómo se usan?

Veamos un ejemplo para aclarar el panorama. Supongamos que tenemos la siguiente interface:

public interface IDataPayasadas
{
     //Propiedades
     string Mensaje { get; set; }
     //Métodos
     void Saludo();
}

Un método Saludo y una propiedad Mensaje.

Supongamos que tenemos la siguiente clase:

public class MyDataPayasadas : IDataPayasadas
{
     string Mensaje { get; set; }
     void Saludo()
     {
          Console.Write(string.Format("Hola mundo! Te traigo un mensaje: {0}", Mensaje);
     }
}

¿Qué fue lo que pasó? Simplemente implementamos la interface IDataPayasadas. ¿Y con eso qué gano? No mucho. Pero, ¿qué pasa si tengo otra clase que implementa IDataPayasadas y quiero usarlas indistintamente? Supongamos la clase:

public class MyDataPayasadasNuevo : IDataPayasadas
{
     string Mensaje { get; set; }
     void Saludo()
     {
          MessageBox.Show(Mensaje);
     }
}

Aquí es donde se ve el beneficio de usar interfaces, ya que puedo llamar al método Saludo indistintamente de su implementación:

public class Program
{
     void Main()
     {
          IDataPayasadas saludo1 = new MyDataPayasadas();
          saludo1.Mensaje = "hola";
          saludo1.Saludo();

          IDataPayasadas saludo2 = new MyDataPayasadasNuevo();
          saludo2.Mensaje = "hola";
          saludo2.Saludo();
     }
}

MyDataPayasadas y MyDataPayasadasNuevo tienen formas diferentes de mostrar el mensaje, pero como implementan la interface IDataPayasadas puedo estar tranquilo de que si o si van a tener una propiedad Mensaje y un método Saludo.

También podemos implementar más de una interface. La forma de hacerlo es:

public class MyClase : IDataPayasadas, ICloneable
{
     ...
}

También puede ser que una clase derive de otra y a la vez implemente varias interfaces:

public class MyClase : MyClaseBase, IDataPayasadas, ICloneable
{
     ...
}

Podemos verificar si una clase implementa una interface mediante la palabra clave is:

if(MyDataPayasadas is IDataPayasadas)
{
     MyDataPayasadas.Saludo();
}
else
{
     Console.Write("No implementa IDataPayasadas");
}

¿Cuál es la diferencia con una Clase Base Abstractas?

Las clases base abstractas además pueden definir constructores, variables de campo, miembros no abstractos (con implementación), etc.

En cambio las interfaces solo definen miembros abstractos.

Hay toda una serie de escenarios y motivos por los cuales son diferentes, pero escapa del objetivo de este post que es acercarles una introducción a lo que son las interfaces y para que pueden ser útiles.

Resumiendo:

• Las interfaces son puro protocolo: definen qué comportamientos debe tener la clase, pero no se puede definir cómo implementarlos.
• Los miembros son por defecto públicos y abstractos. No es necesario definir el scope de cada miembro.
• No puede contener variables de campo
• No puede definir constructores
• No puede contener implementaciónes
• Las interfaces no se pueden instanciar!!! (No intenten hacer IDataPayasadas dp = new IDataPayasadas();)
• Las interfaces se pueden usar como tipo, por lo tanto podemos pasarlas como parámetros, como tipo de retorno de un método, podemos crear arrays de interfaces (IDataPayasadas[] dps = {new MyDataPayasadas(), new MyDataPayasadasNuevo()};)

Espero que les sea de utilidad! Cualquier duda o sugerencia pregunten nomas. Saludos!

Buenas amigos… me he encontrado con este problemita de la división por cero en Reporting Services 2005.

Lo primero que pensé fue en hacer algo como esto:

=IIF(Fields!Numerador.Value <> 0, (Fields!Numerador.Value) / (Fields!Denominador.Value), 0)

Pero resulta que el IIF siempre ejecuta tanto la expresión de la parte verdadera como la expresión de la parte falsa y por eso siempre va a devolver #Error.

Ahora bien, una pequeña chanchada que podemos hacer para evitar ésto es:

=IIF(Fields!Numerador.Value <>  0, (Fields!Numerador.Value) / (IIF(Fields!Denominador.Value <> 0, Fields!Denominador.Value  0, 1), 0)

Qué fue lo que hicimos? Simplemente engañamos al IIF cuando el denominador es 0. Cuando eso ocurre de todas formas el primer IIF va a devolver 0 pero ya la expresion (Fields!Numerador.Value) / (Fields!Denominador.Value) no va a dar #Error ya que estaríamos dividiendo por 1 y no por 0.

No es lo mejor ni lo mas óptimo, pero remitiendome a las palabras de mi amigo Carlos A.:
“Primero que funcione, despues que funcione bien, y por último que funcione como uno quiere.”

Salutes!

Para recuperar un parametro del QueryString en un WebPart de SharePoint:

Supongamos que queremos recuperar el valor de tipo int del Parametro IdProyecto en el QueryString:

using System.Web;
.
.
.

int idProyecto = Convert.ToInt32(HttpContext.Current.Params["IdProyecto"]);

Espero que les sirva. Saludos!

Buenasss como les va? Esta vez me trae por aquí este tema de los reportes. Resulta que me han pedido que haga un reporte donde pueda filtrar los valores a mostrar en el reporte pero desde el Report Viewer en una página Aspx…

Empecemos por el reporte. Supongamos que tenemos un reporte que debe mostrar un listado de proyectos y quiero elegir cuales mostrar y cuales no.

El reporte es bastante sencillo de hacer:

SELECT ID, Nombre, Descripcion FROM Proyectos WHERE ID IN(@IdProyectos)

@IdProyectos es un parámetro del reporte que admite múltiples valores.

Finalmente le damos el estilo visual al reporte, agregando una tabla con los campos del DataSet.

Hasta aquí es bastante sencillo.

Luego, en nuestra página ASPX agregamos un ListBox, un botón (para cargar el reporte) y el ReportViewer.

Luego, para pasarle los valores al reporte:

BindingList parametrosReporte = new BindingList();</code>

ReportParameter idProyectos = new ReportParameter("IdProyectos");

for (int i = 0; i < listProyectos.Items.Count; i++)
{
        idProyectos.Values.Add(listProyectos.Items[i].Value;
}

parametrosReporte.Add(idProyectos);

Con esto creamos un parámetro de reporte y lo agregamos a la colección. Luego tenemos que asignar estos parámetros al ReportViewer que insertamos en la página. Para ello podemos usar el siguiente código:

try
{
        ReportViewer1.ServerReport.SetParameters(parametrosReporte);
}
catch
{
        //Manejamos la excepción
}

Y listo. Espero que les sea de utilidad!!!

Saludos

Buenas. Hoy me topé con un problemita. Tenia que abrir en una ventana nueva una página pasandole un parametro por query string. Como lo estaba haciendo del lado del servidor me encontré con que Response.Redirect no tiene forma de pasarle el target ya que esto es un concepto del lado cliente.

Por suerte encontré este snippet que funcionó:

Response.Write("<script type='text/javascript'>window.open('TuPagina.aspx?parametro=1');</script>");

La desventaja que tiene esto es que se produce un Postback en la página que hace el llamado. Si necesitamos generar la URL en forma dinámica esta es una buena alternativa. Espero que les sea útil!

Saludos

Recientemente me tocó armar una pequeña aplicación que debía tomar desde el repositorio de Team Foundation Server los items de trabajo de todos los proyectos asignados a mí, que no hayan sido completados o eliminados.

Para ello utilicé el siguiente código:

private WorkItemCollection GetTareasTFS()
    {
        try
        {
            string serverTFS = "http://servidor:puerto"; //El puerto generalmente es 8080

            // Creo la conexión y pido credenciales si no las tengo
            TeamFoundationServer tfsServer = TeamFoundationServerFactory.GetServer(serverTFS, new UICredentialsProvider());
            tfsServer.EnsureAuthenticated();

            //Obtengo el WorkItemStore
            WorkItemStore workItemStore = tfsServer.GetService(typeof(WorkItemStore)) as WorkItemStore;

            //Creo una consulta que trae todos los items que no fueron terminados ni eliminados
            //y que fueron asignados a mi
            string query = string.Format("SELECT [System.Id], [System.WorkItemType]," +
                " [System.State], [System.AssignedTo], [System.Title] " +
                " FROM WorkItems " +
                " WHERE [System.Title] <> '' AND [System.State] <> 'Done' AND [System.State] <> 'Deleted' AND [System.ChangedBy] = '{0}'" +
                " ORDER BY [System.WorkItemType], [System.Id]", tfsServer.AuthenticatedUserDisplayName);
            //Ejecuto la consulta
            WorkItemCollection workItemCollection = workItemStore.Query(query);

            //Devuelvo la colección de workItems
            return workItemCollection;
        }
        catch (Exception ex)
        {
            //Manejo la excepción
        }
    }

Ademas hay que agregar referencias a los siguientes assemblies:

• Microsoft.TeamFoundation.Client
• Microsoft.TeamFoundation.WorkItemTracking.Client

Es bastante sencillo. A partir de ahí puedo iterar sobre la colección para sacar los campos que me interesan, o bien bindear la colección a algún control. Espero que les sea útil!

Saludos!

UPDATE! Para que esto funcione deberemos tener instalado el Team Explorer!