El pasado sábado 28 de enero se realizó, en Barcelona, el segundo evento catdotNet, dedicado a la exposición de temas actuales relacionados con la plataforma .NET y otras tecnologías de Microsoft. Aunque ha pasado una semana desde entonces, no quería dejar de escribir una breve reseña sobre lo acontecido en el encuentro.

El evento lo abrió Eduard Tomàs con la disertación Cómo realizar una app metro style con C# y Expression Blend. En Windows 8 tendremos dos categorías de aplicaciones. Por una parte, existirán las aplicaciones de escritorio (Desktop) de toda la vida, en un entorno visual muy similar al de Windows 7. Por otra, existirán (en realidad, coexistirán) las aplicaciones Metro style, optimizadas para la interacción táctil y pensadas para ser usadas en dispositivos móviles tipo tablets. Eduard se centró en estas últimas, y en describir una de las vías que tendremos los desarrolladores para programarlas: la dualidad XAML-C#.

En Modo Desktop seguiremos programando con .NET, como en Windows 7, y las aplicaciones que corran allí serán capaces de ejecutarse en Windows 8. Las aplicaciones Metro style, que ocuparán siempre toda la pantalla (full screen), como sus parientes de Windows Phone 7, requieren un nuevo modelo de desarrollo.

Es aquí donde entra en escena WinRT. Haremos la interfaz gráfica con XAML (también se podrá hacer con HTML5 y CSS3), y en el code behind usaremos C# u otro lenguaje como VB.NET para realizar llamadas a WinRT, que se expondrá como si fuesen clases reales de .NET. Básicamente será como lo que hoy hacemos con WPF y Silverlight.

Eduard enfatizó en este último punto. Explicó que de Silverlight a Metro hay un paso. Que XAML es muy parecido. Y que para el code behind tendremos que aprender WinRT.

En mi anterior post puse un enlace a The WinRT Genome Project, donde se realiza una comparación entre Silverlight y WinRT. Allí vemos que algunas cosas quedarán fuera, que la mayor parte de Silverlight quedará incluida en WinRT, y que tendremos muchas cosas nuevas para estudiar y aprender.

Microsoft se esforzó con Windows Phone 7 en ofrecer herramientas que facilitaran la fluidez de las aplicaciones mientras son ejecutadas. En Windows 8 también dispondremos de herramientas para dotar de fluidez a las aplicaciones Metro. Esencialmente dispondremos de mecanismos simples para realizar llamadas asíncronas. C# 5 nos ofrece las directivas async y await para que las llamadas a métodos asíncronos sea tan sencilla como una llamada a métodos síncronos.

Eduard utilizó la versión 11 de Visual Studio, que viene en la preview de Windows 8, para mostrarnos una sencilla aplicación de WinForm que realiza llamadas asíncronas a un método que podría bloquear la interfaz gráfica del programa mientras se ejecuta. Naturalmente, tal bloqueo no ocurre y la interfaz continúa respondiendo fluidamente. Justo lo que se pretende con las directivas async y await. Por cierto, el orador no dejó pasar la ocasión y destacó que estábamos viendo una aplicación de Windows Form en Windows 8.

Luego de la demostración, conocimos cómo será el Ciclo de Vida de una aplicación Metro. En cada momento sólo se ejecutará una aplicación. Ésta puede pasar al estado Terminada, o puede pasar a Suspensión, desde donde también podría terminar su ejecución. La sensación de déjà vu fue inmediata. Ya tenemos ese esquema en Windows Phone 7.

En el teléfono existen algunos casos especiales que son excepciones. Por ejemplo, una aplicación que reproduzca archivos de música puede pasar a un segundo plano y ser suspendida. Sin embargo, si utiliza el servicio adecuado puede seguir reproduciendo la música mientras en primer plano se ejecuta otra aplicación.

Es el caso de easyTube, una excelente aplicación que disfruto y recomiendo. Permite ver, descargar y almacenar vídeos de Youtube en el teléfono. Pero en el caso que nos ocupa, podemos reproducir el sonido de los vídeos de forma contínua, uno tras otro, mientras ejecutamos otra aplicación. En cuanto a Windows 8, no quedó claro en la presentación si existirán este tipo de excepciones, aunque yo apostaría con los ojos cerrados a que sí.

Por último, vimos cómo se integrarán las aplicaciones Metro con la pantalla de inicio. Tendremos los Lives Tiles, muy parecidos a los que ya tenemos en el teléfono. Además de servir de punto de inicio de la aplicación, como sucede con los viejos iconos, es un espacio dinámico que puede mostrar información variable, incluso si la aplicación no se está ejecutando.

En ellos veremos los badges, pequeños iconos o números que nos informan de algún suceso. Por ejemplo, en el teléfono, cuando recibimos correos o mensajes, aparecen esos numeritos en los correspondientes Live Tiles indicándonos que los hemos recibido y cuántos han entrado.

También existirán notificaciones (toasts), parecidas a las que aparecen en el área de notificación de Windows 7, que pueden enviar las aplicaciones, incluso aunque no se estén ejecutando (Scheduled Toasts).

A continuación intervinieron otros ponentes. Alex Casquete nos explicó cómo desarrollar aplicaciones Windows Metro Style con HTML5, CSS3 y Javascript. Toni Recio habló de Natural User Interfaces, Microsoft Kinect y WPF, y realizó una divertida demostración. Y por último, Rodrigo Corral e Ibon Landa nos hablaron sobre Optimización y rendimiento de aplicaciones con Visual Studio y Windows Azure.

Debido a la extensión del evento, he decidido dejar para futuras entradas las reseñas de estas tres intervenciones. Todas resultaron de gran calidad e interés, y considero que, por méritos propios, cada una merece un post en exclusiva.

Nota: Fotos tomadas con mi teléfono móvil.

¿Alguna vez has deseado ver el estado del tráfico desde cualquier lugar? Con Cámaras DGT puedes ver una selección de las imágenes de las cámaras publicadas por la Dirección General de Tráfico y servicios afines. Puedes escoger aquellas que prefieras y guardarlas como favoritas. Así podrás visualizarlas cómodamente cada vez que ejecutes la aplicación. Necesitas conexión a internet para ver las imágenes.

Descarga Cámaras DGT para Windows Phone 7

Es gratis

Cámaras DGT es mi primera aplicación para Windows Phone 7. Muestra imágenes estáticas publicadas por la Dirección General de Tráfico, los ayuntamientos de Madrid y Barcelona, y el Servei Català de Trànsit. Puede que en un futuro próximo agregue más cámaras de otras comunidades y ciudades españolas. ¿Quieres ver tu ciudad? No dudes en contactarme.

La aplicación ha estado disponible en el Marketplace desde hace un mes y medio. Exactamente desde el 14 de noviembre de 2011. A pesar del corto tiempo que lleva publicada, me ha sorprendido agradablemente el número de veces que ha sido descargada, no sólo en España, sino también en el resto de los países desde donde se puede descargar.

El proceso de creación resultó ser también un proceso de aprendizaje. Uno de los puntos fuertes de Windows Phone 7, desde el punto de vista del desarrollador .NET, es que parte de la experiencia previa y los conocimientos adquiridos en otras áreas de la plataforma son utilizables o extrapolables al sistema de desarrollo del teléfono. La dualidad XAML+C#, presentada bajo el nombre de Silverlight for Windows Phone, no es nueva. Ya la tuvimos en WPF (Windows Presentation Foundation), en Silverlight (originalmente llamado WPF/Everywhere), y la tendremos en pocos meses en el futuro Windows 8 bajo el nombre de WinRT (Windows Runtime).

Luego están los temas realmente nuevos. No solamente hay que aprender la colección de nuevos controles Silverlight, propios del teléfono móvil, o las nuevas clases que realizan tareas asociadas a este tipo de dispositivo. Hay que conocer también el nuevo y premiado lenguaje de diseño visual Metro. Hay que entender la filosofía que subyace en él. Y hay que comprender que aquí no se diseña como se hace para iOS o Android.

Windows Phone 7 es un universo nuevo, emocionante y en expansión, que se apoya en tecnologías maduras de Microsoft. Es una propuesta diferente. Ha llegado último a la fiesta pero, como dicen en mi pueblo, no van lejos los de alante si los de atrás corren bien. La empresa de Redmond está desarrollando una estrategia global de largo recorrido, que pasa por su alianza con Nokia, la adaptación de Metro para tablets en Windows 8, la reciente actualización de la interfaz de la Xbox con Metro, el fuerte apoyo a los desarrolladores y una inusual campaña de márketing (centrada fundamentalmente en los Estados Unidos), entre otras acciones. Definitivamente, el nuevo año 2012 se presenta como una etapa muy interesante de eso que han dado en llamar la era post PC.

NOTA: Cuando escribí el refrán No van lejos los de alante… me asaltó la duda. ¿Debería haber dicho adelante? Por mucho que la RAE no acepte el vocablo, si lo hubiese cambiado habría falseado la literalidad de la frase tal como la escuché siempre y como permanece viva en el habla popular. Una búsqueda en internet me llevó al Blog de la Lengua. Tanto el artículo como la aportación muy interesante de los comentaristas ofrecen bastante luz al respecto.

Enlaces de interés:

Silverlight for Windows Phone
http://www.microsoft.com/silverlight/windows-phone/

Windows Presentation Foundation
http://es.wikipedia.org/wiki/Windows_Presentation_Foundation

Silverlight 5 released; will there be a Silverlight 6?
http://arstechnica.com/microsoft/news/2011/12/silverlight-5-released-will-there-be-a-silverlight-6.ars

WinRT demystified
http://tirania.org/blog/archive/2011/Sep-15.html

The WinRT Genome Project
http://thewire.vertigo.com/2011/the-winrt-genome-project/

Metro (design language)
http://en.wikipedia.org/wiki/Metro_(design_language)

Introduction To Designing For Windows Phone 7 And Metro
http://uxdesign.smashingmagazine.com/2011/12/20/introduction-designing-windows-phone-7-metro/

Interfaz de Windows 8 al descubierto: Metro UI para todos
http://www.genbeta.com/sistemas-operativos/windows-8-para-tablets-al-descubierto-interfaz-metro-para-todos

Xbox 360 se viste de Metro para llevarse mejor con Windows Phone y Kinect
http://www.xataka.com/consolas-y-videojuegos/xbox-360-se-viste-de-metro-para-llevarse-mejor-con-windows-phone-y-kinect

En la época del iOS, Android, BlackBerry OS, e incluso de un casi recién nacido Windows Phone 7 que pretende crecer de forma acelerada, hablar de Windows Mobile puede parecer demodé, fuera de moda. Y lo es. “Microsoft ha matado a su sistema operativo Windows Mobile“, decía en mi entrada anterior Cómo abrir el menú Inicio en Windows Mobile con C#. Con el objetivo de recuperar parte del terreno perdido, Microsoft ha venido realizando un amplio conjunto de acciones dirigidas a estimular el mercado de Windows Phone 7. De momento, el mercado se resiste.

“Visual Studio 2010 no admite el desarrollo de aplicaciones para móviles para las versiones de Windows Phone anteriores a Windows Phone 7.0.“, puede leerse en la MSDN. Visual Studio 2008 es la última versión del entorno de desarrollo que podemos utilizar para crear aplicaciones de Windows Mobile. Quizás ésta sea una de esas acciones que comentaba antes, en este caso dirigida a desestimular el apego por la vieja plataforma.

Copio y pego un párrafo de mi anterior entrada sobre movilidad:

“¿Quiere decir ésto que ya hay que olvidarse, como desarrollador, de Windows Mobile? Quizás. Pero allá afuera hay un legado de aplicaciones antiguas que necesitan ser mantenidas, y lo cierto es que las nuevas tendencias en los desarrollos móviles están influyendo en los criterios de mantenimiento de aplicaciones que fueron creadas sobre una plataforma ya obsoleta.”

Si hoy tuviera que crear una aplicación de movilidad desde cero, no la haría para Windows Mobile. Pero si tuviera que mantener una aplicación desarrollada para esa plataforma, no lo haría como se hacía hace varios años. Utilizaría ideas de diseño modernas que superan las capacidades nativas de Windows Mobile. Por ejemplo, la posibilidad de usar imágenes y botones con fondo transparente.

Para lograr éste y otros tipos de efectos visuales, existen en la red interesantes proyectos de código abierto. He seleccionado uno de ellos muy fácil de usar, AlphaMobileControls, para crear una interfaz más actual y continuar desarrollando el proyecto pedagógico que he utilizado a lo largo de varios post: una sencilla aplicación que sirve para hacer llamadas telefónicas, ocupa toda la pantalla y permite abrir el menú Inicio.

AlphaMobileControls ofrece pocas clases y controles:

Basta con sustituir en la aplicación antigua los Windows.Forms.Form por AlphaForm, o los Windows.Forms.Panel por AlphaPanel. Encima de ellos podemos colocar los botones, imágenes y etiquetas que necesite el programa. El código de ejemplo demuestra cómo hacerlo. Para los botones he utilizado un psd de la colección openPhone, creado por Walrick. Descarga el código del proyecto Teléfono v3.

Otros proyectos de interés:

Windows Mobile – Attractive UI: Part I
http://www.codeproject.com/KB/windows/Windows_Mobile_UI.aspx
(Explica cómo funciona internamente AlphaMobileControls)

Silvermoon
http://silvermoon.codeplex.com/

Composite UI Framework for Windows Mobile
http://mobileui.codeplex.com/

Fluid – Windows Mobile .NET Touch Controls
http://fluid.codeplex.com/

Touch UI
http://touchui.codeplex.com/

En varias ocasiones he tenido que instalar el SQL Server 2008 R2 Express, y aunque, en general, la instalación suele terminar como uno espera que termine, a veces se presentan situaciones inesperadas, a primera vista sin una explicación lógica, como la que quiero contar hoy.

Tenía que instalar el SQL Server 2008 R2 Express sobre un Windows 7. Ambos estaban en idioma español. Ejecuto el instalador, como tantas veces, y me sale un mensaje que nunca antes había visto:

Lo primero que me llama la atención es que el mensaje sale en inglés. “Quizás descargué la versión equivocada”, pienso, y reviso seguidamente el archivo de instalación que poco antes había bajado del sitio web de Microsoft. No, no había bajado la versión equivocada. Había descargado el instalador del SQL Server 2008 R2 Express traducido al castellano.

Vuelvo a leer el mensaje, intentando comprender su significado: SQL Server setup media does not support the language of the OS… “Esto no puede ser”, pienso. Tanto el Windows como el instalador están en el mismo idioma. ¡Esto no tiene sentido! Vamos a ver qué nos tiene que decir San Google al respecto.

Google me devuelve como primer resultado un interesante hilo en Microsoft Connect, donde se discute el asunto y se ofrecen soluciones.

Al parecer, los de Microsoft han sido más rigurosos que en versiones anteriores con el SQL Server 2008 R2, en relación con los idiomas soportados, y aparentemente en esta “mejora” se les ha colado un bug. La “mejora” la explican en el propio hilo:

Todo ésto está muy bonito, pero resulta que estoy haciendo lo que Max Verun dice que hay que hacer, y ésto no me resuelve el problema.

Releyendo el hilo, y buscando en otros resultados de Google, encuentro que una posible solución consiste en modificar el formato del idioma del sistema operativo. Gente de Chile o México, que tenían sus PCs en español de Chile o de México, resolvieron el problema cambiando el formato del idioma a español de España. ¡Fantástico! Pero resulta que a mí no me sirve, ¡porque mi Windows ya estaba en español de España!

Quizás, si fuera chileno o mexicano podría resolver el problema de esta manera.

¡Y ésta es la solución!

Ve al Panel de Control y abre la ventana de Configuración regional y de idioma. Cambia el formato del idioma a otro cualquiera  (Español de Chile o México, por ejemplo) y acepta los cambios. Vuelve a abrir la misma ventana, pon el formato a Español (España) y acepta nuevamente. Y voilà. Ahora la instalación del SQL Server 2008 R2 Express no debería mostrar el error.

Enlaces de interés:

SQL Server setup media does not support the language of the OS
http://connect.microsoft.com/SQLServer/feedback/details/556958/sql-server-setup-media-does-not-support-the-language-of-the-os

Versiones en idioma local en SQL Server
http://msdn.microsoft.com/es-es/library/ee210665(v=SQL.105).aspx

Microsoft ha matado a su sistema operativo Windows Mobile. Tras los numerosos retrasos en el desarrollo de Windows Mobile 7, aceptó sabiamente que el proyecto ya era un fracaso aún antes de ver la luz. iPhone y Android habían tomado la delantera, y amenazaban con dejar fuera de la carrera a quien años atrás había sido el líder. Así que en diciembre de 2008 apretó CTRL+ALT+DEL y comenzó a crear un nuevo sistema operativo para teléfonos inteligentes, apoyándose en tecnologías que ya tenían cierto recorrido: el núcleo de Windows Mobile (Windows CE 6.0 R3), la plataforma .NET, Silverlight y XNA Framework. De esta manera nació el Windows Phone 7.

En cuanto estuvieron disponibles las primeras betas del sistema y de las herramientas de desarrollo, Microsoft inició una frenética cruzada para captar desarrolladores de aplicaciones. Con su ya famoso grito de guerra Developers, developers, developers!, Steve Ballmer reconocía la importancia de este sector en su estrategia global. Windows Phone 7 no tendría futuro si no contaba con su propia tienda de aplicaciones, por lo que tendría que potenciar el ya existente Marketplace.

Microsoft ha intentado convencer a miles de desarrolladores de que el futuro está en WP7, y ha llevado a cabo numerosas acciones para facilitar el aprendizaje de la nueva plataforma tecnológica (Windows Phone 7 Development for Absolute Beginners, Windows Phone 7 Training Course). Después de todo, tiene una tienda que llenar de productos nuevos para ayer mismo. ¿Quiere decir ésto que ya hay que olvidarse, como desarrollador, de Windows Mobile? Quizás. Pero allá afuera hay un legado de aplicaciones antiguas que necesitan ser mantenidas, y lo cierto es que las nuevas tendencias en los desarrollos móviles están influyendo en los criterios de mantenimiento de aplicaciones que fueron creadas sobre una plataforma ya obsoleta.

Hoy en día se tiende a aprovechar todo el espacio físico que ofrece la pantalla del teléfono, maximizando el tamaño de la ventana de la aplicación. Por ejemplo, i-nigma, un difundido lector de códigos QR, utiliza este principio de diseño GUI.

En cierta ocasión viví en primera persona esta historia, pues los usuarios estaban habituados a consultar el calendario y otras aplicaciones mientras utilizaban el programa que me había tocado mantener. Propuse maximizar la ventana, y así se hizo. Tras las primeras pruebas de los key users, las protestas no tardaron en llegar. Tenía dos opciones: o daba marcha atrás y dejaba el diseño de la interfaz como estaba anteriormente, o mantenía el nuevo diseño, más moderno, y ofrecía una solución que resolviera el nuevo problema.

Y la solución fue simular por programación que el usuario hacía click sobre el icono del menu Inicio. ¿Y cómo podemos abrir el menú Inicio en Windows Mobile con C#? Pongamos manos a la obra.

Los teclados que han sido creados específicamente para ser usados en ordenadores con Windows (Microsoft Natural Keyboard) tienen dos teclas especiales que muestran el logotipo de este sistema operativo. Cuando se presiona cualquiera de los dos, el resultado es el mismo: se despliega el menú Inicio. En un dispositivo con Windows Mobile podemos simular esta acción mediante la función keybd_event, que se encuentra en la dll no administrada coredll.dll, por lo que tendremos que utilizar P/Invoke para importarla a nuestro código C#:

[System.Runtime.InteropServices.DllImport("coredll.dll", EntryPoint = "keybd_event", SetLastError = true)]

internal static extern void keybd_event(byte bVk, byte bScan, int dwFlags, int dwExtraInfo);

Una vez que hemos importado esta función, sólo nos resta usarla con los valores adecuados. El código de la tecla izquierda con el logotipo de Windows (Left Windows key) es 0x5B. Tendremos que simular dos eventos: cuando se oprime la tecla, y cuando se libera. El código del primer evento es cero (0×0), mientras que el del  segundo es 2 (0×2). Ahora tendríamos que colocar sobre la interfaz de nuestra aplicación una imagen o un botón, y asociarle un evento que “oprima” y “libere” el menú de inicio. El código fuente en C# quedaría más o menos así:

const int VK_LWIN = 0x5B;
const int KEYEVENTF_KEYUP = 0×2;
const int KEYEVENTF_KEYDOWN = 0×0;

private void btnInicio_Click(object sender, EventArgs e)
{
    keybd_event(VK_LWIN, 0, KEYEVENTF_KEYDOWN, 0);
    keybd_event(VK_LWIN, 0, KEYEVENTF_KEYUP, 0);
}

En este código de ejemplo hemos utilizado la declaración de varias constantes, pero podríamos haber utilizado el tipo enumerativo Keys, del espacio de nombres System.Windows.Forms. El código alternativo y equivalente quedaría así:

private void btnInicio_Click(object sender, EventArgs e)
{
    keybd_event((byte)Keys.LWin, 0, KEYEVENTF_KEYDOWN, 0);
    keybd_event((byte)Keys.LWin, 0, KEYEVENTF_KEYUP, 0);
}

Nótese que hemos necesitado realizar un typecast sobre el valor Keys.LWin, porque la función keybd_event() espera como primer parámetro un valor de tipo byte.

He aprovechado el código de ejemplo de la entrada Cómo hacer una llamada telefónica en Windows Mobile con C# para ampliarlo con esta nueva funcionalidad. Descarga la nueva versión y comprueba su utilidad.

Enlaces de interés:

Cómo abrir el menú Inicio en Windows Mobile con C#
El código fuente del proyecto

keybd_event
http://msdn.microsoft.com/en-us/library/aa928103.aspx

keybd_event (coredll)
http://pinvoke.net/default.aspx/coredll.keybd_event

Virtual-Key Codes
http://msdn.microsoft.com/en-us/library/dd375731(v=VS.85).aspx

Keys Enumeration
http://msdn.microsoft.com/en-us/library/system.windows.forms.keys(VS.90).aspx

How Microsoft Hit CTRL+ALT+DEL on Windows Phone
http://www.wired.com/gadgetlab/2010/11/making-windows-phone-7/all/1

ACTUALIZACIÓN

Windows Phone OS 7.0: What’s inside?
http://www.zdnet.com/blog/microsoft/windows-phone-os-70-whats-inside/6110

¿Porqué sería posible instalar Windows Phone 7 en un smartphone Nokia?
http://logica10mobile.blogspot.com/2011/02/porque-seria-posible-instalar-windows.html

Tienes una aplicación web ASP.NET que lleva tiempo funcionando sin problemas. La desarrollaste en Windows XP con Visual Studio 2005. Hacías las pruebas en local con la versión 5 del IIS, la que viene con el XP Professional, o con el servidor de desarrollo de Visual Studio (Cassini), y en producción tenías un Windows Server 2003 con la versión 6 del IIS. Todo iba como la seda.

Salió el Visual Studio 2008 y, a la primera oportunidad, te subiste al carro de la modernidad. Y, luego de algunos pequeños ajustes, como adaptar el proyecto a la nueva versión de Crystal Reports, todo seguía como la seda.

Pero como en esta vida también hace falta emoción y suspense, la seda dejó de ser lo que era. Los Reyes Magos te trajeron un nuevo ordenador con Vista o Windows 7, o cambiaste el plan de alojamiento del sitio web y ahora tienes Windows Server 2008 en producción. Ambas situaciones tienen un factor común: se llama Internet Information Services 7.

De pronto la aplicación dejó de funcionar. La que cambió su entorno de ejecución de IIS5/6 a IIS7. Si el problema lo tienes en local, quizás dispones de un tiempo generoso para solucionarlo, pero si el problema surgió con el cambio de plan de alojamiento, ahora el tiempo es tu mayor enemigo. Bueno, el tiempo y el dueño de la web caída.

La pregunta es trivial, pero no deja de martillarte tu masa encefálica: ¿qué ha pasado con la web? Miras el código, analizas la arquitectura, ejecutas la aplicación repetidamente… y por fin descubres que el servidor no entiende las URLs que le escribes porque el responsable de procesarlas, el módulo HTTP de reescritura de URLs, ha muerto, ha dejado de existir.

¿Qué ha pasado? Que el IIS7 ha cambiado muchas cosas en su modo de trabajar en relación con versiones anteriores. Mantiene, por compatibilidad hacia atrás, la manera de trabajar antigua, ahora conocida como Modo Clásico, e incorpora una nueva forma de hacer las cosas, que han denominado Modo Integrado. Cuando configuras un nuevo sitio web, el modo de trabajo por defecto es el Integrado. Y si este nuevo sitio web es en realidad una web antigua de ASP.NET, es muy probable que algunas cosas dejen de funcionar, como, por ejemplo, los módulos HTTP.

En el Modo Integrado se ha modificado la manera de registrar los módulos HTTP mediante el archivo web.config. En versiones anteriores del IIS, estos módulos se registraban en la sección <system.web>/<httpModules>. En el Modo Integrado de la versión 7 se registran en la sección <system.webServer>/<modules> del archivo web.config.

Por ejemplo, si has programado el módulo “MiModulo“, el archivo web.config quedaría así:

En versiones anteriores del IIS

<configuration>
<system.web>
<httpModules>
<add name=”MiModulo” type=”MiModulo”/>
</httpModules>
</system.web>
</configuration>

En el Modo Integrado del IIS7

<configuration>
<system.webServer>
<modules>
<add name=”MiModulo” type=”MiModulo”/>
</modules>
</system.webServer>
</configuration>

Tienes la opción de dejar las cosas como estaban, y configurar el sitio web para que se ejecute en el Modo Clásico, pero de esta manera estarías renunciando a las nuevas posibilidades que aporta la última versión del IIS.

Por otra parte, si desarrollas sobre Windows XP y necesitas un IIS7 local para hacer las pruebas y empezar a utilizar los nuevos recursos, ya es posible hacerlo. Microsoft acaba de lanzar una nueva versión del Internet Information Server llamada IIS Developer Express, que forma parte de  WebMatrix. Este nuevo servidor trabaja con VS2010 y Visual Web Developer 2010 Express, se ejecuta sobre Windows XP y sistemas superiores, y no necesita una cuenta de administrador. IIS Developer Express mantiene las mejores características de Cassini (el servidor de desarrollo de Visual Studio) y del IIS7.  Además, es gratis.

Enlaces de interés:

Tutorial: Crear y registrar un módulo HTTP personalizado
http://msdn.microsoft.com/es-es/library/ms227673.aspx

HttpModule and HttpHandler sections in IIS 7 web.config files
http://www.west-wind.com/Weblog/posts/168221.aspx

ASP.NET Integration With IIS 7
http://learn.iis.net/page.aspx/243/aspnet-integration-with-iis-7/

Registering Custom HttpModule in IIS7 Web.config
http://elijahmanor.com/webdevdotnet/post/Registering-Custom-HttpModule-in-IIS7-Webconfig.aspx

ASP.NET 2.0 Breaking Changes on IIS 7.0
http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/

URL Rewriting in ASP.NET
http://msdn.microsoft.com/en-us/library/ms972974.aspx

Introducing IIS Express
http://weblogs.asp.net/scottgu/archive/2010/06/28/introducing-iis-express.aspx

Explore el servidor web de Windows Vista y más allá
http://msdn.microsoft.com/es-es/magazine/cc163453.aspx

Introducción a IIS 7.0
http://technet.microsoft.com/es-es/magazine/2008.03.iis7.aspx

Recientemente un cliente me pidió, como parte de los requerimientos del proyecto, que para realizar ciertas acciones en su aplicación de Windows Mobile se encendiera y apagara el teléfono automáticamente, sin que el usuario tuviera que intervenir. Concretamente, la aplicación tiene que abrir una conexión de datos GPRS, conectarse a un webservice situado en un servidor de Internet, e intercambiar cierta información con éste. El teléfono no se utiliza para comunicaciones de voz, sólo de datos.

Como era una tarea que nunca antes había realizado, tuve que recurrir a Google para intentar encontrar la solución, alguna solución cercana, a alguna pista que me llevara hacia ella. Pronto la decepción se apropió de mí. Por más que buscaba y buscaba cómo encender el teléfono en Windows Mobile con C#, no encontraba nada, a pesar de que la búsqueda la realizaba en Inglés, el idioma más difundido en la red.

Sin embargo, aunque lentamente, poco a poco me fui acercando a la solución. La causa de la falta de respuestas era que no estaba escribiendo la pregunta correcta. Para un usuario común puede que la frase “encender el teléfono” le resultara natural, pero en términos más técnicos el enfoque correcto es “encender la radio del dispositivo móvil”. Y en Inglés. Algo así como: turn radio on and off windows mobile c#. Aunque en este contexto existen otros posibles sinónimos de turn, como switch o toggle.

Resulta que en la ROM del dispositivo existe una dll no documentada llamada ossvcs.dll, que exporta funciones para controlar los Dispositivos de Radio (Radio Devices). Es decir, los módulos de Bluetooth, Teléfono y Red Inalámbrica (WiFi). Ossvcs.dll exporta las funciones por un número de orden y no por su nombre. Estas funciones pertenecen a un API no administrado, por lo que para invocarlas desde nuestro código C# necesitaremos declarar los prototipos mediante p/Invoke. Las funciones que necesitamos son las siguientes:

[DllImport("ossvcs.dll", EntryPoint = "#276", CharSet = CharSet.Unicode)]
private static extern uint GetWirelessDevice(ref IntPtr pDevice, int pDevVal);

[DllImport("ossvcs.dll", EntryPoint = "#273", CharSet = CharSet.Unicode)]
private static extern uint ChangeRadioState(ref RDD pDevice, int dwState, int saveAction);

[DllImport("ossvcs.dll", EntryPoint = "#280", CharSet = CharSet.Unicode)]
private static extern uint FreeDeviceList(IntPtr pDevice);

Nótese cómo EntryPoint contiene el número de orden que identifica a la función invocada.

De las tres funciones, la que realmente nos interesa es ChangeRadioState(), porque justamente es la que nos permite cambiar el estado de la radio. Es decir, encenderla o apagarla. O dicho de forma llana, encender o apagar el teléfono.

He creado una clase llamada MobileRadio, que expone un único método público estático: SetDeviceState(). Este método acepta dos argumentos de tipo entero. El primero indica el tipo de dispositivo, y el segundo informa el estado al que se desea cambiar. El tipo de dispositivo puede ser uno de los siguientes: Bluetooth, el Teléfono o la Red Inalámbrica (WiFi). No necesitas conocer de memoria los valores enteros que se pueden traspasar. La clase MobileRadio exporta también dos estructuras (RADIODEVTYPE y RADIODEVSTATE) que contienen las constantes necesarias.

Para encender el teléfono basta la siguiente línea de código:

MobileRadio.SetDeviceState(MobileRadio.RADIODEVTYPE.PHONE, MobileRadio.RADIODEVSTATE.ON);

Y para apagarlo, ¿lo adivinas?

Para conocer el estado actual del teléfono, si está encendido o apagado, utilizamos la propiedad booleana PhoneRadioOff de la clase SystemState, situada en el espacio de nombres Microsoft.WindowsMobile.Status:

Microsoft.WindowsMobile.Status.SystemState.PhoneRadioOff

Esta propiedad es verdadera (true) si la radio del dispositivo está apagada, y falsa (false) en caso contrario.

Puedes descargar el proyecto completo desde aquí.

Enlaces de interés:

Cómo encender el teléfono en Windows Mobile con C#
El código fuente del proyecto

Turn radio on and off as needed
http://community.intermec.com/t5/General-Development-Developer/Turn-radio-on-and-off-as-needed/m-p/138

Controlling the Radio Devices
http://www.teksoftco.com/articles/article%20007/radiodevices.htm

Toggle WiFi/BT/Phone using .NET code only!!!
http://forum.xda-developers.com/showthread.php?t=413159

PInvoke.net: A wiki for .NET developers
http://www.pinvoke.net/

Un teléfono móvil moderno, provisto de Windows Mobile, nos permite abrir archivos de MS Office, leer PDFs, hacer fotos, leer el correo electrónico, acceder a contenidos online por RSS, llevar la agenda de actividades, gestionar nuestros contactos, escuchar música, ver vídeos, chatear, jugar, ejecutar aplicaciones de un amplio rango… Además, por si no fuera suficiente, también sirve para hacer llamadas telefónicas.

Realizar una llamada telefónica mediante código C# desde una aplicación nuestra de Windows Mobile es algo ridículamente simple, gracias a un recurso que Microsoft ha puesto a nuestra disposición: la clase Phone. Esta clase se encuentra definida dentro del ensamblado Microsoft.WindowsMobile.Telephony (en la DLL microsoft.windowsmobile.telephony.dll), por lo que debemos agregar una referencia a este ensamblado en nuestro proyecto de Visual Studio.

Ahora sólo nos resta declarar y crear un objeto de la clase Phone, y llamar a su método mágico: Talk().

Phone p = new Phone();
p.Talk(numero);

Este método recibe como parámetro un texto (string) que representa el número al cual se desea llamar: public void Talk(string number).

El proceso no es silencioso. Realmente lo que hace es ejecutar (y mostrar) el programa Teléfono del sistema operativo. Delega en él todas las operaciones, como por ejemplo, colgar la llamada.

Puedes descargarte el proyecto completo desde aquí.

¿Y por qué necesitaríamos realizar llamadas telefónicas desde una aplicación propia? ¿Acaso para escribir una versión mejorada del programa nativo? Yo conozco al menos un caso en que sí es necesario acudir a esta funcionalidad. Hace algunos años tuve que desarrollar una aplicación de telecomunicaciones que necesitaba, como parte de su funcionamiento, realizar llamadas automáticamente a un cierto número. La aplicación OIGAA convierte los teléfonos móviles en extensiones de la centralita corporativa, permitiendo a sus usuarios responder desde cualquier lugar como si estuvieran en la oficina, y ofreciendo además diversas funcionalidades de valor añadido. Aquí te dejo algunas capturas de pantalla de la aplicación ejecutándose en el emulador de dispositivos móviles.

• OIGAA: Pantalla de autenticación
• OIGAA: Conexión y actualización inicial de datos
• OIGAA: Agenda de contactos. Posibilidad de iniciar una conexión de VoIP
• OIGAA: Configuración del tipo de llamada y el mensaje de presencia

Enlaces de interés:
Código completo del ejemplo

Con el lanzamiento de la versión 2.0 de la plataforma .NET, Microsoft incluyó soporte para entornos de 64 bit basados en microprocesadores Itanium y x64. Las anteriores versiones 1.1 y 1.0 no ofrecían este tipo de soporte.

El entorno de desarrollo de aplicaciones .NET (SDK, Visual Studio 2005) permite compilar las aplicaciones en tres modos diferentes: sólo para ser ejecutadas sobre 32 bit, sólo para ser ejecutadas sobre 64 bit, o compiladas sólo para lenguaje intermedio (MSIL). En este último caso los ensamblados no contienen información específica de la plataforma hardware de destino, por lo que se conoce como modo agnóstico.

Teóricamente, una aplicación .NET compilada en modo agnóstico, el modo por defecto en que compila Visual Studio 2005, se puede ejecutar indistintamente en entornos de 32 ó 64 bit. Bastaría con desplegarla en cualquiera de los dos entornos. Sin embargo, no siempre el escenario es tan simple.

La clave para que una aplicación sea multiplataforma es la ausencia de dependencias del hardware en el código. Por lo tanto, para migrar una aplicación de 32 a 64 bit es necesario investigar la aplicación para determinar si existen dependencias de bajo nivel. Si se detectaran, habría que estudiar cada caso ya que no existen recetas universales. Por dependencias de bajo nivel entendemos la utilización de APIs nativas (como la Win32) o de objetos COM.

Esta investigación debe dirigirse en dos direcciones: (1) descubrir y corregir las posibles dependencias del código fuente de la aplicación (nuestro código), y (2) analizar y evaluar las componentes de terceros. Si alguna de estas componentes no cumpliera los requisitos debería ser sustituida por otra equivalente válida.

De forma resumida, se dice que una aplicación está escrita con código seguro si sólo se ejecuta en el entorno del CLR, o sea, no se utilizan punteros de forma explícita ni llamadas de tipo pInvoke (llamadas a código no administrado, como la API Win32). Esto implicaría que nuestro código no esté atado al hardware, que es lo que buscamos para que la aplicación pueda ejecutarse correctamente sobre 32 y 64 bit.

Una pregunta común en esta situación es: ¿Cómo saber en qué entorno se ejecuta la aplicación? Cuando ejecutemos la aplicación migrada, sería útil conocer si realmente está corriendo sobre 64 bit. Sabemos que los punteros sobre 32 bit ocupan 4 bytes, mientras que sobre 64 bit tienen un tamaño de 8 bytes. Entonces, basta con conocer en tiempo de ejecución este dato.

La estructura IntPtr, del espacio de nombres System, nos resultará útil para averiguarlo. Esta estructura contiene una propiedad entera estática llamada Size, que nos devuelve justamente lo que necesitamos: un 4 si estamos en .NET 32 bit, o un 8 si estamos sobre 64 bit.

Puede verse claramente ahora que una aplicación que utilice punteros podría realizar operaciones que dependan de su tamaño. Si la aplicación “piensa” que está sobre 32 bit, pero está sobre 64, el resultado de estas operaciones no tiene que ser el que se esperaba. Con gran probabilidad se generará un error.

Conocer las zonas de nuestro código que no son seguras nos ayudará a decidir si las convertimos en código seguro, o si las hacemos dependientes de una arquitectura específica.

Para investigar si el código de nuestra aplicación es seguro Microsoft ofrece con el SDK una herramienta que se llama Peverify.exe, que podemos utilizar para analizar todas las DLLs que genera el proyecto.

Deberemos eliminar todas las referencias a objetos COM, buscando soluciones alternativas en cada caso, siempre basadas en código administrado.

Por último, debemos verificar en el entorno de desarrollo Visual Studio 2005 que la compilación de la solución se realice en modo agnóstico (Any CPU), que es el modo por defecto.

Hasta aquí habríamos “limpiado” o “asegurado” nuestro código para que se ejecute transparentemente sobre 32 o 64 bit pero, ¿qué pasa si dependemos de componentes de terceros? Estas también tienen que haber sido desarrolladas con código seguro y haber estado compiladas en modo agnóstico. Si no se cumplen estas dos condiciones habría que sustituir las componentes inadecuadas para 64 bit por otras que sí lo sean.

Para conocer si han sido escritas con código seguro podemos usar nuevamente la herramienta PEVerify, analizando cada uno de los ensamblados ajenos.

El problema de conocer cómo han sido compilados estos ensamblados ajenos se resuelve mediante la Reflexión, la capacidad del entorno de ejecución de .NET de acceder a los metadatos de los ensamblados y obtener información sobre los mismos. Si obtenemos el mensaje de ILOnly, es decir, modo agnóstico (sólo lenguaje intermedio), ya hemos llegado a la meta. Si no fuera así, tendrá que buscar componentes sustitutas que le ofrezcan las mismas funcionalidades y, además, sean aptas para entornos de 64 bit o multiplataforma. Depende de cuáles sean sus objetivos.

El siguiente ejemplo muestra cómo obtener la información que buscamos:

Al ejecutar GetAssemblyInfo() obtendremos la siguiente cadena de caracteres:

Ensamblado de System.DateTime: ‘mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′. Compilado para: ‘ILOnly, Required32Bit’ – Plataforma: ‘I386′

Es decir, la versión de System.DateTime que estamos utilizando pertenece al ensamblado mscorlib, que está compilado en modo agnóstico.

Enlaces de interés:

Migrating 32-bit Managed Code to 64-bit
http://msdn.microsoft.com/en-us/library/ms973190.aspx

64-Bit .NET Framework
http://msdn.microsoft.com/es-es/netframework/aa496329(en-us).aspx

64-bit (From Wikipedia, the free encyclopedia)
http://es.wikipedia.org/wiki/64_bits

Microsoft 64-bit Computing Overview
http://www.microsoft.com/servers/64bit/overview.mspx

Herramienta PEVerify Tool (Peverify.exe)
http://msdn.microsoft.com/es-es/library/62bwd2yd(VS.80).aspx

System.IntPtr.Size
http://msdn.microsoft.com/es-es/library/system.intptr.size(VS.80).aspx

Si desarrollas para .NET, es muy probable que algunas de tus búsquedas en Internet te hayan llevado a las páginas del Guille. Pues bien, el Guille está realizando una gira por los grupos de usuarios de .NET de España durante los meses de Octubre a Diciembre. Esta semana (ayer) visitó Barcelona, donde estuvo acompañado por David Salgado, “evangelista” de Microsoft.

El encuentro comenzó puntualmente a las 18:00 horas. Con un tono jocoso e informal, el Guille nos fue introduciendo en las nuevas características de la plataforma .NET desde la perspectiva de la versión 9.0 de Visual Basic.NET. Entre chiste y chiste, habló de Ensamblados Amigos, Relajación de Delegados, Agilidad del Runtime y Tipos Anulables. Me sorprendió saber que esta última característica de los Tipos Anulables (Nullable Types) se introdujo en VB.NET con el Visual Studio 2008, puesto que ya la teníamos en C# desde la versión 2.0 de la plataforma y Visual Studio 2005. Lo mismo ocurre con la Relajación de Delegados (Covarianza y Contravarianza).

A continuación, el Guille presentó el Operador Ternario, Los Métodos Parciales, la Inferencia de Tipos, los Tipos Anónimos y LINQ, uno de los recursos más novedosos de Visual Basic.NET 9.0 (y también de C# 3.0). Explicó, además, las nuevas posibilidades para inicializar objetos y colecciones, las Expresiones Lambda y los Métodos de Extensión. Varias de estas nuevas características se introdujeron para darle soporte a LINQ.

Durante casi exactamente dos horas, los asistentes al evento disfrutamos de las habilidades comunicativas y la sabiduría del conferencista. Con un lenguaje claro, directo y sencillo, fue exponiendo los fundamentos de los nuevos recursos de VB 9.0, a la vez que respondía las preguntas del público. Finalmente dió paso a su compañero David Salgado, con quien había bromeado en varias ocasiones sobre la clásica disputa de Visual Basic.NET vs C#.

A diferencia del Guille, David no trajo una presentación de PowerPoint. Prefirió ir armándola en vivo mientras explicaba los conceptos, a partir de los intereses manifestados por los participantes. Comenzó hablando de la capacidad de multitargeting del Visual Studio 2008. O sea, ahora Ud. puede decidir para qué versión de la plataforma quiere compilar su proyecto: 2.0 o 3.5. Si aún trabaja con proyectos de la versión 2.0, puede resultarle útil hacerlo con Visual Studio 2008, y sacarle provecho a las nuevas funcionalidades del entorno que aumentan la productividad. Por ejemplo, si desarrolla un proyecto de ASP.NET ahora puede beneficiarse del IntelliSense cuando escriba código JavaScript.

David explicó el Client Profile, un subconjunto de la versión completa de .NET Framework 3.5 SP1 destinado a las aplicaciones cliente que proporciona un subconjunto simplificado de las características de WPF, Windows Forms, WCF y ClickOnce. Hizo énfasis en las ventajas de ASP.NET MVC, fundamentalmente para equipos de desarrollo grandes. Ejemplificó la utilidad de ADO.NET Data Services y de ASP.NET Dynamic Data. Esta última tecnología permite generar un completo sitio web de mantenimiento de una base de datos. Hasta ahora el sitio web de mantenimiento lo hacíamos “a mano”, o utilizábamos una herramienta como Iron Speed. En ASP.NET  puedes ver un vídeo que explica cómo generar el sitio (en Inglés).

Respecto a la próxima versión de Internet Explorer, David no ahorró elogios. Destacó la fidelidad a los estándares del nuevo IE8, el cuidado de la privacidad mientras navegamos (InPrivacy Browsing), mayor seguridad y privacidad al evitar que sitios de terceros realicen un perfil de nuestros hábitos (InPrivacy Blocking), nuevos mecanismos que facilitan la ejecución de tareas asociadas a las páginas (Accelerators, antes conocidos como Activities), mejoras en el rendimiento de JavaScript, herramientas integradas para desarrolladores…

Como siempre sucede, el tiempo no alcanza para ver todo lo que se podría ver. Microsoft se ha encargado en los últimos años de atiborrarnos de nuevas tecnologías, y resulta un poco difícil seguirle el ritmo. Sin embargo, hay que decir que también ha realizado un gran trabajo para poner a disposición de la comunidad un sinfín de recursos para el aprendizaje de estas nuevas tecnologías, que evolucionan a una velocidad de vértigo. Y eventos como el Guille Community Tour 2008 forman parte de sus líneas de actuación. Muchas gracias, Guille y David, por ayudarnos a transitar el infinito camito del conocimiento.