Hasta ahora no había realizado más que pequeñas pruebas de LINQ, pero recientemente he cambiado de proveedor de hosting (al de momento magnífico discountASP) que ya proporciona soporte para .NET 3.5 y me he decidido a usarlo un poco más.

En concreto he creado una nueva página de links, donde he puesto de momento los links que tengo alojados en del.icio.us y mis elementos compartidos de Google Reader, que es el lector RSS que utilizo.

Tanto del.icio.us como Google Reader proporcionan acceso a los elementos públicos mediante una URL que ofrece un documento RSS en el primer caso (http://del.icio.us/rss/amezcua) y un documento ATOM en el segundo (http://www.google.com/reader/public/atom/user/06770480527490995101/state/com.google/broadcast).

Teniendo esto en cuenta, el funcionamiento de la página es realmente sencillo. Sin entrar en detalles los pasos realizados son:

1º Al cargar la página se obtiene un documento XML a partir de la URL para cada uno de los documentos anteriores. Esto es tan sencillo como:

XDocument xmlDoc = XDocument.Load(urlServicio);

2º Una vez se dispone del documento se obtiene, mediante una consulta LINQ, una colección de elementos extrayendo los datos deseados del XML original. Por ejemplo, para el caso de del.icio.us se quiere obtener una colección de objetos con dos campos, 'title' y 'url':

var itemList = from item in xmlDoc.Descendants("{http://purl.org/rss/1.0/}item")
select new { title = (string)item.Element("{http://purl.org/rss/1.0/}title"),
url = (string)item.Element("{http://purl.org/rss/1.0/}link")
};

3º Cuando se tiene la colección creada (itemList) se puede utilizar DataBinding para vincular esta lista de elementos a cualquier control. En mi caso lo he vinculado a un control DataList. En el control DataList simplemente se especifica que se quieren mostrar los campos 'title' y 'url' definidos antes:

dlDelIcioUsItems.DataSource = itemList;
dlDelIcioUsItems.DataBind();

Como se puede ver hay, sin contar el control de errores, 4 líneas de código para cargar un documento XML remoto y mostrarlo en una página Web, bastante impresionante, teniendo en cuenta que para hacer algo similar hasta ahora lo que hacía era disponer de una clase que defina la estructura del documento, cargar el XML remoto en un XmlReader, deserializar el documento a la clase y finalmente obtener la colección de items interna de esa clase.

Una de las cosas que hay que destacar es el uso de los namespaces de XML. Como se ve en la consulta LINQ, para acceder a cada uno de los elementos del documento hay que especificar el namespace XML en el que se encuentra

{http://purl.org/rss/1.0/}

lo que define completamente al elemento XML concreto. Esta sintaxis, tal como está en el ejemplo, no me acaba de gustar, así que se puede mejorar de la siguiente forma:

XNamespace deliciousNS = "http://purl.org/rss/1.0/";
var itemList = from item in xmlDoc.Descendants(deliciousNS
+ "item") select new {
title = (string)item.Element(deliciousNS + "title"),
url = (string)item.Element(deliciousNS + "link")
};

En este caso se define un objeto XNamespace con el namespace adecuado y se utiliza en todos aquellos sitios donde se necesite especificar el nombre completo del elemento. Como el tipo XNamespace sobrecarga el operador '+' se puede usar simplemente añadiendo entre comillas el nombre del elemento XML. Esto no se encuentra en la mayoría de los ejemplos publicados por ahí sobre LINQ to XML, donde se utilizan documentos XML sin definición de namespaces, cosa que no es muy habitual en el mundo real ¿no?

Como complemento a la nueva versión de SQL CE (la base de datos compacta pensada para usar principalmente en dispositivos Windows Mobile), han liberado recientemente una herramienta que puede resultar muy interesante en ciertos casos.

Como la mayoría que haya usado SQL CE sabrá, SQL CE se puede sincronizar con bases de datos SQL Server. La base de datos SQL CE se conecta con el servidor SQL Server vía HTTP y permite sincronizar su contenido con el servidor.

Según se publica en el blog de SQL CE, esta nueva herramienta permite realizar una sincronización similar pero con bases de datos Access. Esto permite que, por ejemplo, dispongamos de una aplicación móvil con SQL CE y, al conectar el dispositivo móvil al PC, la base de datos del dispositivo se sincronice con una base de datos Access en nuestro PC.

Esta sincronización se realiza con las siguientes características:

• La conversión de tipos de datos entre SQL CE y Access se realiza en el momento de hacer la sincronización.
• Es necesaria una conexión de ActiveSync para que la sincronización se produzca.
• No es necesario instalar nada en el dispositivo. Simplemente hay que instalar software en el PC.
• La sincronización se basa en RDA (RDA es uno de los métodos de sincronización disponibles; en SQL Server se cuenta con RDA y Merge).
• Una aplicación existente en una PDA se puede hacer que sincroniza con SQL Server o Access simplemente cambiando los parámetros de sincronización, pero no es necesario modificar nada más.
• No existe resolución de conflictos.

Aún no la he usado mucho, pero tengo en mente un par de casos donde me podría resultar útil, ya veremos...

Si la queréis probar está disponible aquí.

Coincidiendo con el lanzamiento de Visual Studio 2005 Service Pack 1, Microsoft ha liberado SQL Server Compact Edition (antes SQL Server Everywhere) cuya principal novedad, como ya comenté anteriormente, es la posibilidad de disponer de bases de datos SQL CE (archivos con extensión .sdf) tanto en el PC como en dispositivos móviles (Pocket PCs, SmartPhones, ...) con una base de código común. Esto abre un interesante abanico de posibilidades y nuevos escenarios que hasta ahora no eran posibles.

Además de SQL CE, se han liberado las herramientas de desarrollo correspondientes que faciliten el desarrollo de estas soluciones.

Cada vez es más común realizar operaciones asíncronas, gracias en parte a la llegada de la Web, donde no podemos bloquear una aplicación simplemente porque esté haciendo una operación de red que no sabemos el tiempo que va a tardar en concluir, como una llamada a un servicio Web. Cuando realizamos una aplicación de este estilo, hay que 'mantener al usuario entretenido' de alguna forma, para que sepa que la operación está teniendo lugar y que la aplicación no se ha quedado 'colgada', idealmente dando la posibilidad de cancelar la tarea.

Una manera de indicar que se está realizando una operación de este estilo que me gustó hace tiempo fue la que implementa la ventana de inicio de sesión de SQL Server Management Studio, donde se ve una pequeña barra que muestra un gradiente de colores animado mientras se está validando al usuario.

Este UI es muy poco intrusivo y muestra claramente la intención. De hecho, en Outlook 2007 se ha copiado y se puede ver encima del panel de lectura de un mensaje cuando Outlook tarda en abrir el mensaje por cualquier motivo.

Siguiendo esta idea, cree un control hace tiempo para un proyecto, mostrando una barra animada mientras se está accediendo a un servicio Web. Os dejo aquí la implementación que realizé. Consiste en un control que expone tres propiedades ForeColor, MiddleColor y BackColor. El control crea un gradiente entre los tres colores en toda su superficie, quedando estéticamente bien cuando el tamaño del control es alargado y estrecho. Luego expone dos métodos, Animate y StopAnimation que lo animan. La animación realizada hace que el gradiente 'rebote' de lado a lado de la barra horizontal.

Adjunto al control un proyecto de prueba donde se puede ver enseguida lo que hace. No lo he portado aún a .NET Compact Framework, pero no creo que sea difícil si alguien lo quiere hacer.

Espero que resulte interesante.

Hasta el momento hoy se han anunciado varios lanzamientos que pueden resultaros interesantes.

Por un lado, ya está disponible el redistribuible de .NET Framework 3.0, incluyendo novedades como WPF (Windows Presentation Foundation, ó Avalon), WCF (Windows Communication Foundation, ó Indigo) y WWF (Windows Workflow Foundation).

Por otro lado, también está disponible la RC1 de SQL Server Compact Edition (aunque al instalarla aparece aún como SQL Server Everywhere).

Además, Office 2007 ya es RTM (versión final) y se ha anunciado en las subscripciones MSDN que todos los subscriptores tendrán disponibles tanto Office 2007 como Windows Vista para descargar en un plazo de 7 días después del anuncio, así que habrá que estar al tanto.

Finalmente, hoy empieza el TechEd en Barcelona (donde hay varias presentaciones sobre Windows CE 6.0 que se lanzó la semana pasada), con lo que probablemente se producirán más anuncios interesantes a lo largo de los próximos días; pondremos la antena a ver qué se cuece.

Así es, la versión compacta de SQL Server vuelve a cambiar de nombre, al parecer para quedarse con SQL Compact Edition. Tenéis todos los detalles en el blog de Steve Lasker.

Al parecer, estará disponible en pocas semanas la versión 3.1, cuya ventaja principal es la de poder usarse en cualquier entorno, incluido Windows 2000. Ya están planificadas también las demás versiones con cambios en el motor de sincronización y la posibilidad de adaptarse a más situaciones.

Si habéis leído mi post anterior probablemente habréis comprobado mi tendencia a usar en muchas ocasiones el camino más largo para llegar a un sitio dado.

Como era de esperar, esto también funciona en .NET Compact Framework:

System.Environment.OSVersion.Version

(un poco más facil que lo anterior ¿no?)

Esta propiedad devuelve un objeto de tipo Version que tiene sobrescrito el método ToString para obtener el string de versión habitual (x.x.xxxx); aunque también da acceso a los diferentes componentes de la versión.

Como bonus, podéis examinar un poco más la clase Environment y veréis que podéis obtener lo siguiente:

• Versión del runtime de .NET en ejecución - System.Environment.Version
• Directorios especiales (necesarios para acceder a los directorios en caso de que se ejecute la aplicación en equipos con diferentes idiomas, ej. "Startup" vs "Inicio") - Enum System.Environment.SpecialFolder, usado con la función System.Environment.GetFolderPath
• Tiempo que lleva el equipo encendido - System.Environment.TickCount

Recordatorio final: Antes de hacer nada, mirar si ya está implementado, antes de hacer nada, mirar si ya está implementado, antes de hacer nada, mirar si ya está implementado, antes de hacer nada, mirar si ya está implementado, antes de hacer nada, mirar si ya está implementado, antes de hacer nada, mirar si ya está implementado.

A veces es necesario saber la versión del sistema operativo sobre la que está ejecutándose una aplicación .NET para tomar alguna deción sencilla. El ejemplo más claro que me he encontrado recientemente es el de usar la función Bitmap.Save en .NET Compact Framework para guardar un Bitmap a disco. Si se lee la documentación de esta función, se indica que se le puede pasar un parámetro de tipo ImageFormat (un enum) diciéndole el tipo de imagen a guardar. Entre los diferentes valores del enum se dispone de PNG por ejemplo. Pero si se intenta guardar un bitmap usando el formato PNG en un dispositivo Windows Mobile 2003 (cuya base de sistema operativo es Windows CE 4.2) obtendremos una excepción en tiempo de ejecución (NotSupportedException) ya que en Windows CE 4.2 GDI no dispone de la posibilidad de tratar PNGs. En cambio, si se ejecuta ese código en un dispositivo Windows Mobile 2005, basado en Windows CE 5.0, funcionará sin problemas.

Para evitar estos problemas basta con que detectemos la versión del sistema operativo para escoger un formato de imagen u otro dependiendo del tipo de dispositivo que sea.

Una forma de obtener rápidamente la versión del sistema operativo es mediante la función GetVersionEx del API de Windows. Su declaración sería similar a lo siguiente:

[DllImport("coredll.dll")]
public static extern int GetVersionEx(byte[] lpVersionInfo);

Si se busca la documentación de esta función, como parámetro se pide una estructura de tipo OSVERSIONINFO. En este caso (como en muchos otros en los que el API requiere estructuras) resulta casi más fácil pasarle a la función como parámetro un array de bytes que luego la función rellenará. Lo que necesitamos saber, eso si, es el tamaño del array a pasar, que se puede ver en la documentación (sumando los tamaños de los campos de la estructura). Luego, cuando la función rellene el array, se podrá leer fácilmente su contenido usando la clase BitConverter, lo que facilita mucho las declaraciones de p/invoke, ya que no hay que traducir las estructuras a .NET. Esta misma técnica está usada en el ejemplo de Ping para Compact Framework que podéis encontrar aquí.

Teniendo en cuenta esto, el código para obtener la versión será entonces algo parecido a:

byte[] lpVersionInfo = new byte[138];

int resp = GetVersionEx(lpVersionInfo);
if (resp == 1)
{
Int32 dwMajorVersion = BitConverter.ToInt32(lpVersionInfo, 4);
Int32 dwMinorVersion = BitConverter.ToInt32(lpVersionInfo, 8);
Int32 dwBuildNumber = BitConverter.ToInt32(lpVersionInfo, 12);
Int32 dwPlatformId = BitConverter.ToInt32(lpVersionInfo, 16);

}

Para un equipo con Windows Mobile 2003 el valor de dwMajorVersion será 4 y el de dwMinorVersion será mayor o igual a 2 (Windows CE 4.2). En el caso de un equipo Windows Mobile 2005 la versión será mayor o igual a 5.0.

Siguiendo el ejemplo anterior, la función Bitmap.Save pasándo como parámetro un formato de tipo PNG, funcionará sólo para equipos con dwMajorVersion >= 5.

Recientemente he estado leyendo varios artículos y blogs que hablan sobre el patrón singleton. Su objetivo es asegurar que, dada una clase concreta, se dispone de una única instancia de ella en una aplicación.

La referencia principal sobre patrones es el libro “Design Patterns: Elements of Reusable Object-Oriented Software” donde se explica cómo funciona de manera genérica.

La gente sigue muchas veces al pie de la letra el libro y eso puede hacer que no se tengan en cuenta detalles del lenguaje o la plataforma que se esté utilizando y se llegue a situaciones que puedan complicarse, generándose errores en el código difíciles de detectar.

En el caso de .NET, hay una discusión bastante a fondo sobre el tema en el artículo “Exploring the Singleton Design Pattern”, donde se tienen en cuenta las ventajas del entorno concreto, evitando así muchos de los problemas que pueden darse si se intenta hacer una implementación directa según se copia el código del libro.

Teniendo esto en mente, en C# el código para un Singleton es bastante sencillo:

public class MiClase
{
 private MiClase() {}

 public static readonly MiClase Instance = new MiClase();

 public void HazAlgo()
 {
  …
 }
}

Como se ve, la implementación básica consta de 2 líneas de código, un constructor privado y una variable estática (Instance en este caso) que da acceso a la instancia única. Para entender los detalles de por qué esto funciona así, leer con detalle el artículo mencionado arriba.
A la instancia (única) de la clase se accederá desde el código cliente de la siguiente forma:

…
MiClase.Instance.HazAlgo();
…

Bajo mi punto de vista, esto queda muy limpio y sencillo de usar.

Los usos que se le pueden dar al Singleton son múltiples, como por ejemplo clases que almacenan información de configuración de la aplicación, clases para hacer logs, etc. Eso sí, ojo con su uso en aplicaciones web ya que podéis encontraros con problemas de concurrencia si no se tiene cuidado.

Acude al taller que se celebra el día 27 de abril de 2006 en Barcelona.

Yo participo como ponente en una de las sesiones.

Aunque se puede usar .NET Compact Framework 2.0 y SQL Mobile 2005 en Pocket PC 2003 (basado en Windows CE 4.2) no hay soporte en otros dispositivos Windows CE 4.2, por ejemplo en los dispositivos industriales.

Este hecho ha recibido quejas desde distintos frentes (MVPs, clientes, ...) y, con la llegada de .NET Compact Framework 2.0 SP1 esto se va a solucionar, lo que alegrará a más de uno.

Hay más detalles en el blog de Mike Hall.

Ya está disponible la biblioteca de componentes Microsoft Enterprise Library para .NET Framework 2.0. Para aquellos que no sepan de qué va porque no hayan trabajado con las versiones anteriores, son un conjunto de componentes que implementan 'buenas prácticas' de código en tareas comunes de programación con .NET (acceso a datos, logs, gestión de excepciones, etc). Desde al punto de vista práctico son un buen paquete de componentes gratuitos que funcionan bien y que te ahorrarán mucho tiempo de desarrollo con .NET ;-)

Según publica Brad Adams, ya está disponible una versión preliminar de WinFX que funciona con la versión final de Visual Studio 2005.

Sigue siendo una versión pre-beta, pero al menos permite probar Indigo y Avalon en la versión final del entorno de desarrollo.

Es necesario descargar el WinFX runtime, el SDK de WinFX (OJO, 1Gb) y los componentes de WinFX para Visual Studio 2005 (el link para este componente que hay ahora en el blog de Brad no funciona, supongo que funcionará en breve).

Con la llegada de la versión 2.0 de .NET Compact Framework, que se puede instalar en cualquier dispositivo Windows Mobile .NET o Windows Mobile 5.0, es posible incluir archivos de configuración de manera similar a como se hace en aplicaciones de escritorio basadas en Windows Forms.

Para el que no lo sepa, si se tiene un ejecutable llamado "app.exe", su archivo de configuración correspondiente se llamaría "app.exe.config" y, si está presente, el runtime de .NET lo leerá y procesará.

Una de las cosas que se pueden configurar en este archivo es la versión de .NET con la que se quiere ejecutar el programa. Esto permite fijar una versión de .NET a una aplicación dada y permite también que aplicaciones hechas con la versión 1.0 se ejecuten con la versión 2.0, aprovechando automáticamente sus ventajas.

David Kline explica en su blog cómo hacer este archivo de configuración. Hay que tener en cuenta que 'en principio' no debería haber ningún problema en realizar esta modificación, pero, como siempre, la única manera de saberlo es probando...

He estado probando un poco el desarrollo de aplicaciones Web con ASP.NET 2.0 y una de las cosas que más me gustan es el poder usar las capacidades de DataBinding de los controles para vincularlas a objetos en lugar de a bases de datos.

Una de las cosas que quería probar era ver si podía vincular un control de tipo GridView a unos objetos que creé hace tiempo que obtienen leen RSS. Estos objetos conectan con un documento RSS cualquiera y obtienen sus elementos en una colección, en el número que se le pida (por ejemplo los 3 últimos elementos).

Teniendo en cuenta esto, mi primera prueba fue intentar usar el asistente que trae Visual Studio 2005 para vincular controles a datos y seleccionar la plantilla de ObjectDataSource. Este asistente pide que se seleccione la clase que contiene los objetos a vincular, el nombre del método a llamar en esa clase y sus parámetros para obtener los datos que se mostrarán en el control deseado.

Esto aparentemente funciona sin más pero al intentar ejecutar la página apareció la excepción 'No parameterless constructor defined for this object'. En efecto, mi objeto no tiene un constructor por omisión sin parámetros. Mi objeto en concreto funciona pasándole unos parámetros al constructor que indican dónde está el documento RSS, el nombre de usuario y contraseña si son necesarios, etc. Una vez construida la instancia, se puede llamar al método que carga los datos.

Buscando en las propiedades del control proporcionado por Visual Studio no encontré ninguna forma de pasarle una instancia. Leyendo posteriormente la documentación, se indica que cuando se usa este origen de datos, el objeto ObjectDataSource crea una nueva instancia del componente que conecta a los datos llamando a su constructor sin parámetros. Después llama al método dado con los parámetros que se le pasen. Esto no me vale para mi objeto. Por otro lado parece bastante poco flexible ya que (al menos en mi caso) en la mayoría de los objetos que conectan a datos, antes de poder conectar establezco valores en propiedades que luego las instancias de los objetos usan para trabajar. Con el modelo planteado eso tampoco funcionaría.

Pero como no me gusta darme por vencido tan fácilmente, probé a usar el objeto ObjectDataSource directamente en el código de la página y ¡bingo!, existe un evento al que nos podemos suscribir para modificar la instancia que ObjectDataSource utiliza. El proceso es el siguiente:

• Crear una instancia de ObjectDataSource indicándole la clase  que ha de usar y el nombre del método a llamar que traerá los datos.
• Indicarle el nombre y valores de los parámetros que necesita el método anterior para traer los datos.
• Crear un handler para el evento ObjectDataSource.ObjectCreating. En este handler se tiene acceso a la instancia que se va a usar, pudiendo sustituirla.
• Usar la instancia que hayamos creado de ObjectDataSource como origen de datos del control que se vaya a usar.
• Llamar a DataBind en el control, esto hará que se ejecute el método que conecta con los datos

En código C# sería algo así:

protected void Page_Load(object sender, EventArgs e)
{
    // Una instancia de mi objeto
    _blogClient = new BlogClient(p1, p2, p3, p4);

    // Creo el ObjectDataSource indicándole la clase a usar
    ObjectDataSource ods = new ObjectDataSource("Caladan.BlogClient.BlogClient", "GetRssEntries");
    ods.SelectParameters.Add("ItemCount", "5");

    // Establezco el handler
    ods.ObjectCreating += new ObjectDataSourceObjectEventHandler(ods_ObjectCreating);

    // Vinculo al control Web (un DataList en este caso)
    dlBlog.DataSource = ods;
    dlBlog.DataBind();
}

void ods_ObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
    // Aquí se tiene acceso a la instancia, que modifico por la mía ya creada
    e.ObjectInstance = _blogClient;
}

Y ya está, con estos simples pasos se pueden usar todas las técnicas de data binding del control Web pero con un origen de datos que no es una base de datos. Tengo que hacer notar que el resultado de la llamada a GetRssEntries (el método de mi objeto que lee el RSS) es una colección de tipo CollectionBase, con lo que la iteración entre los distintos elementos ya viene dada (por implementar IEnumerable).

No se a vosotros, pero a mí esto me ayuda bastante…

.NET Compact Framework 2.0 está disponible oficialmente desde ayer con lo que la mayoría de los dispositivos que hay por ahí no lo incluyen ;-)

Para instalarlo existen dos opciones. Una es obtener los 'redistribuibles' y hacer la instalación del archivo .msi desde el PC a través de ActiveSync.

La otra opción es mediante Visual Studio 2005 o el SDK de .NET Framework 2.0. Si se usa este camino, en algunos dispositivos la instalación se puede hacer desde dentro del entorno de desarrollo, pero en otros no funciona.

Para los que no funciona hay que copiar el archivo .cab de manera manual al dispositivo y ejecutarlo para que se instale. El archivo a copiar es NETCFv2.wm.armv4i.cab para dispositivos Windows Mobile 2005 y NETCFv2.ppc.armv4.cab para dispositivos Windows Mobile 2003. Estos archivos se encuentran en el directorio de instalación del SDK. En el caso de una instalación de Visual Studio 2005 el directorio es similiar a:

\Program Files\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\wceXXX

donde XXX es la versión del S.O. wce400 para Windows Mobile 2003 y wce500 para Windows Mobile 2005. Tenéis más información en el blog de Marcus Perryman.

Todavía queda alguna plaza...

Yo estaré por allí el sábado...

Mi amigo Unai acaba de publicar un artículo interesante en la revista Microsoft Technical Journal de MSDN sobre cómo configurar la replicación RDA y la replicación Merge entre un servidor SQL Server 2005 y SQL Mobile (la nueva versión de SQL Server para dispositivos).

Es interesante ver la distinción entre los dos tipos de técnicas para poder escoger la más adecuada a nuestra situación, ya que el uso de una u otra depende finalmente de la aplicación a desarrollar.

Seguro que os resultará interesante.

Esta mañana se supone que me llega mi nuevo Pocket PC Phone. Es un i-Mate JasJar con Windows Mobile 5.0.

En cuanto lo reciba quiero migrar algunas aplicaciones que tengo hechas con .NET Compact Framework 1.0 a la versión 2.0 y ver cómo funcionan en el nuevo sistema.

Cuando lo tenga resuelto iré contando las experiencias.

Ya está disponible la versión final (RTM) de Visual Studio 2005 para los suscriptores de MSDN.

Ojo si quieres programar con WinFX, porque la versión pública de WinFX no es compatible con esta versión de Visual Studio, sólo con la Beta 2.

Si tienes instaladas versiones anteriores de Visual Studio 2005 y quieres actualizar, hay que hacer varias cosas (hasta 23 pasos) aunque hay una herramienta que puede ser útil. Más información sobre esto en: http://www.sellsbrothers.com/news/showTopic.aspx?ixTopic=1894

Y si tu interés está en el desarrollo para dispositivos y quieres saber qué herramientas usar para qué tipo de dispositivos de los que hay disponibles, aquí tienes un cuadro que cruza las versiones de las herramientas de desarrollo con las de los equipos:

http://blogs.msdn.com/windowsmobile/archive/2005/06/02/424382.aspx

Pues eso, que si tenéis una suscripción a MSDN, ya está disponible para descarga la imágen del DVD de Visual Stucio 2005 RC. Es una versión más reciente que la Beta 2, aunque no está cubierta por la licencia GoLive (con lo que no hay soporte para ponerla en producción).

He añadido una nueva utilidad a la sección de herramientas. Se trata de un componente que permite enviar ‘pings’ de ICMP a equipos remotos desde aplicaciones Compact Framework en dispositivos Windows Mobile 2003.

Podéis descargar sólo el ejecutable para Pocket PC, aunque también disponéis del código para incorporarlo en vuestras aplicaciones.

Espero que resulte interesante.

Recientemente me he encontrado con dos proyectos donde el uso de Visual C++ .NET ha ahorrado mucho tiempo y esfuerzo.

En ambos casos el problema estaba en cómo crear ‘wrappers’ en .NET para acceder a varios APIs nativos (Win32). Uno estaba relacionado con el acceso a APIs de Windows y el otro es un API propietario de un fabricante de unos equipos de video digital.

Inicialmente en los dos proyectos se intentó primero la creación de un ‘wrapper’ en C#. Esta aproximación siempre suena razonable, pero en cuanto el API a usar sea un poco elaborado, donde se necesite el uso de estructuras complejas, o necesitemos el uso de ‘callbacks’, la situación se complica bastante y, lo que en principio parecía una tarea sencilla, se convierte en horas y horas de intentar definir cómo escribir correctamente los tipos de datos para que se pasen adecuadamente al API, probar las modificaciones y obtener errores difíciles de depurar.

Mediante el uso de Visual C++ .NET y aproximando el problema de otra manera, es bastante fácil crear este tipo de ‘wrappers’. La idea usada en los dos casos anteriores fue la siguiente:

• Crear un proyecto de class library en Visual C++ .NET.

• En ese proyecto se crea una clase C++ .NET (que incluye las extensiones ‘manejadas’). Esta expone las propiedades y métodos deseados a la aplicación .NET final, que se desarrollará en el lenguaje .NET seleccionado, ya sea VB.NET o C#.

• En el mismo proyecto se incluye una clase no manejada (Win32) que es la que hará uso del API nativo requerido.

• La clase C++ .NET usará esta otra clase Win32 interna de manera exclusiva, exponiendo la funcionalidad del API a través de su interface .NET.

De esta manera, no hay que hacer traducciones complejas de estructuras ya que se usan de manera natural dentro de C++. En el caso de funciones de callback, estas se pueden exponer al exterior como eventos o delegados, convirtiéndose en algo natural también a la hora de su uso desde la aplicación cliente final.

Es cierto que hay que conocer algo de C++ para utilizar esta aproximación, pero como su uso se centra en algo bastante concreto, merece la pena hacer ese esfuerzo inicial que se traduce posteriormente en menos dolores de cabeza.

Aquí tenéis un link a una serie de artículos que me pasó mi amigo David García como referencia http://www.ondotnet.com/pub/a/dotnet/2004/03/29/mcpp_part3.html

Ya te puedes registrar para asistir a Microsoft Developer Days 2005.

Este año, al igual que el año pasado, colaboro con MSDN España en la sesión dedicada a desarrollo para dispositivos móviles.

Espero verte por allí.

Recientemente he recomendado este web a David, un amigo mío, que estaba buscando la manera de controlar el volumen del sistema desde una aplicación Visual Basic .NET.

Después de buscar bastante encontró la manera de hacerlo, pero el ejemplo estaba en Visual Basic 6 y me preguntó sobre cómo adaptar algunas partes del código a .NET, entre ellas las sentencias 'declare' de VB6.

Antes de aventurarnos a definir la declaración, probar, fallar, depurar y redefinir, no hay nada como aprovechar lo que ofrece Internet para ahorrar tiempo. 2 minutos en pinvoke.net y ahí estaban las declaraciones en VB.NET y C#.

Y recordad, está en formato WIKI, de manera que si no encontráis la declaración que os hace falta pero conseguir hacerla por vuestra cuenta, por favor, añadirla al site, que así nos beneficiamos todos ;-)

Si eres suscriptor de MSDN, y quieres empezar a jugar con Indigo y WinFX, ya puedes hacerlo porque el Community Technical Preview de Marzo ya está disponible para descargar.

Yo sólo he empezado a probar WinFX, así que no puedo dar todavía ninguna opinión sobre Indigo, pero en cuanto lo pruebe comentaré algo por aquí ;-)

Si queréis una lista de referencias de artículos organizados por temas sobre programación para SmartPhone, principalmente con .NET Compact Framework, no tenéis más que acudir aquí. Están en inglés, eso si.

He añadido una nueva herramienta al Web que puede que os sea útil. Esta herramienta permite copiar una estructura de directorios de un sitio a otro, ya sea en la máquina local o en la red, sin copiar los archivos originales.

Permite realizar esta operación de manera recursiva, incluyendo todas las carpetas (y sus subcarpetas) del directorio de origen.

A mi me ha resultado útil para el mantenimiento de estructuras de carpetas donde almaceno archivos de log, y en migraciones de servidores.

Espero que os pueda servir también.

Cuando se desarrollan aplicaciones para dispositivos móviles, ya sean aplicaciones hechas con .NET Compact Framework, con Win32 o aplicaciones WAP, es muy útil usar el emulador de Windows Mobile para poder probar su funcionamiento sin necesidad de un dispositivo físico. El emulador se lanza habitualmente desde dentro del entorno de Visual Studio .NET y se integra completamente con el depurador, de manera que se puede avanzar el código paso a paso mientras la aplicación se ejecuta en el emulador.

De hecho, si se instala el SDK de Windows Mobile 2003 se instalan las nuevas imágenes de Windows CE .NET 4.2, con emuladores de Pocket PC 2003, Pocket PC 2003 Phone Edition y SmartPhone 2003.

Pero en algunas ocasiones es interesante lanzar el emulador por si sólo, sin necesidad de pasar por Visual Studio, por ejemplo para realizar alguna demostración de una aplicación terminada. Pero no existe ningún acceso directo ni icono que permita realizar esta tarea. Si habéis instalado el SDK mencionado arriba, podéis arrancar el emulador sin pasar por Visual Studio de la siguiente forma (suponiendo que lo habéis instalado en C:\ con las rutas por omisión):

Para arrancar el emulador con una imagen de Pocket PC 2003

"C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\ConnectionManager\Bin\emulator.exe" /ethernet shared /CEImage "C:\Program Files\Windows CE Tools\wce420\POCKET PC 2003\Emulation\PPC_2003_WWE_VIRTUAL_RADIO.bin" /skin "C:\Program Files\Windows CE Tools\wce420\POCKET PC 2003\Emulation\phone\Pocket_PC_PE_Emulator_Skin.xml"

Para arrancar el emulador con una imagen de SmartPhone 2003

"C:\Program Files\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\ConnectionManager\Bin\emulator.exe" /ethernet virtualswitch /CEImage "C:\Program Files\Windows CE Tools\wce420\SMARTPHONE 2003\Emulation\SP_2003_WWE_VIRTUAL_RADIO.bin" /skin "C:\Program Files\Windows CE Tools\wce420\SMARTPHONE 2003\Emulation\Smartphone_Emulator_Skin.xml"

Estos comandos los podéis incluir en un archivo .bat para lanzarlos con un sólo icono.

Además es muy fácil crear 'skins' personalizadas con lo que podéis modificar el aspecto del dispositivo si queréis dar una imagen distinta.

Por otro lado, si queréis probar la aplicación en distintos idiomas, también podéis descargar imágenes de Pocket PC y SmartPhone individuales, en idiomeas distintos, para probarlas por separado.

Recientemente se la liberado una nueva versión de FxCop (v 1.312).

Para los que no lo conozcáis, FxCop es una herramienta que permite examinar código .NET compilado (.dll, .exe) y comprobarlo contra una serie de reglas, obteniendo un informe final de cumplimiento de las mismas. La herramienta dispone de un gran número de reglas predefinidas, agrupadas por temas, como Seguridad, Estilo, etc. El informe final muestra el cumplimiento o no de las reglas seleccionadas, y si no se cumplen da la razón concreta y por qué debería cumplirla, de manera que se pueda decidir sobre si se debe modificar el código antes de entregarlo al usuario final.

Además la herramienta es extensible, es decir, podemos crear nuestras propias reglas y verificar si se cumplen o no en las aplicaciones que desarrollemos. Esto es muy útil en el caso de equipos de desarrollo donde se establecen unas determinadas normas de estilo y codificación que todos los programadores han de seguir. Con esta herramienta es muy sencillo verificar el cumplimiento de las reglas y decidir si un determinado componente de código ha de incluirse en la aplicación final o ha de modificarse.

Pero es mejor probar la herramienta (gratuita) que leer sobre ella. La última versión la podéis descargar aquí.

Buscando información para la creación de controles para Windows Forms me he topado con este sitio que no conocía: GDI+ FAQ (http://www.bobpowell.net/faqmain.htm).

Si desarrolláis aplicaciones gráficas o controles de usuario, este sitio contiene un buen número de técnicas para haceros la vida más fácil.