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 de Windows Mobile con C#, no encontraba nada, a pesar de que la búsqueda la realizaba en Inglés, el idioma más extendido 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

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.