El punto de inflexión para .NET Client Profile

Recientemente, hemos comenzado la preparación del despliegue de la aplicación de escritorio (basada en .NET Framework 3.5 SP1) que estamos terminando de desarrollar. Como la aplicación debe poder instalarse en equipos con Windows XP SP2 ó SP3 que no tengan .NET Framework instalado de antemano, la instalación de la aplicación debe incluir el despliegue de éste. Y fue en este punto donde nos pareció razonable la idea de utilizar .NET Client Profile, un subconjunto muy streamlined de .NET que reduce en buena medida el tiempo de instalación en los equipos de destino. Pero rápidamente nos dimos cuenta de que eso no iba a ser posible para nuestra aplicación. Después de crear un instalador y ejecutarlo sobre una máquina XP, la aplicación falló al ser lanzada, mostrando la siguiente excepción:



Resulta que nuestra aplicación utiliza una librería de componentes de un conocido fabricante (después de esto, he comprobado que otros paquetes de componentes populares “adolecen” del mismo problema). Este fabricante, en aras de ofrecernos una mayor potencia durante el desarrollo, incorpora en sus clases posibilidades pensadas para ser utilizadas por nosotros durante tiempo de diseño dentro de Visual Studio. Y esas posibilidades se apoyan en la utilización de un ensamblado, System.Design.dll, que no forma parte del Client Profile. Si se “desensambla” System.Design.dll con Reflector o con el propio Visual Studio, quedará claro por qué Microsoft no incluyó este ensamblado en el Client Profile. Este ensamblado concentra recursos para el diseño de aplicaciones y servicios de todo tipo, y depende estáticamente de un mogollón de otros ensamblados (incluyendo System.Web.dll); el propio concepto de Client Profile moriría si todo eso formara parte de él.


Pensando sobre el tema, me parece interesante la cuestión de si se resolverá (y cómo) este problema en el futuro. Si estos fabricantes de componentes quisieran dar soporte al Client Profile sin quitarnos las facilidades de tiempo de diseño de las que ya disponemos, deberían modificar sus librerías para que no tengan una dependencia estática de System.Design.dll, sino que carguen este ensamblado dinámicamente (mediante Reflection) cuando sea necesario (que será solo en tiempo de diseño). Otra alternativa sería ofrecer la posibilidad de generar directamente versiones de las librerías de componentes que no dependan de ese ensamblado, mediante una combinación de directivas de compilación condicional y comandos de generación (recuerde que estas librerías se venden con código fuente). Pero, ¿se tomarán ese trabajo esos fabricantes? .NET Client Profile tiene sentido principalmente para equipos basados en XP, puesto que Windows Vista ya incluye de serie .NET 2.0 y 3.0. ¿No preferirán “hacer la vista gorda” y esperar a que termine el soporte para Windows XP? El tiempo dirá.

Octavio Hernandez

Desarrollador y consultor en tecnologías .NET. Microsoft C# MVP entre 2004 y 2010.

4 comentarios en “El punto de inflexión para .NET Client Profile

  1. Vaya…
    Pues yo me encuentro en esa misma situación en una aplicación en la que estoy trabajando: Fw 3.5 y despliegue en XP.
    Pensaba utilizar el Client Profile, pero dado que la aplicación también utiliza “una librería de componentes de un conocido fabricante”… creo que al final será que no 😛
    Gracias por ahorrarme los quebraderos de cabeza 😉

    Sobre lo que comentas de como se solucionará el problema… pues no lo tengo nada claro, pero si no se soluciona será la muerte del concepto del Client Profile, porque vale que Vista tenga el 3.0 de serie, pero cuando salga el Framework 4.0 estaremos en las mismas, no???

    Saludos!

  2. Hola, Eduard!

    Comprueba si de verdad es necesaria esa dependencia, tal vez no necesites los ensamblados concretos de esa librería que dependen de System.Design. Por desgracia, yo sí…

    Los paquetes a los que me refería en el post eran Infragistics y Developer Express.

    Salu2 – Octavio

  3. Sobre lo que dices de .NET 4.0, yo espero que para esa época ya MS se haya decidido a poner a .NET como un requisito básico que se actualice a través de Windows Update. El framework ya ha alcanzado un tamaño tal, que desplegarlo como parte de nuestras instalaciones es un verdadero c…

    Slds – Octavio

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *