Muchas veces me preguntan las diferencias que hay entre el clásico ejecutable que generamos con WPF y que instalamos en el cliente y el concepto de XBAP que es una aplicación WPF también pero que es ejecutada a través del Navegador. Aunque los dos tipos de aplicaciones son hechas con WPF a la hora de diseñar la aplicación hay que tener muy claro si se va a elegir un modelo u otro.
Asi como el tipico ejecutable de WPF se instala como siempre en el cliente (xcopy, click-once) y con seguridad por defecto Full-trust que luego puede ser cambiado por el administrador del equipo, XBAP tiene una serie de restricciones que tenemos que tener en cuenta. La primera es que no se instala en el equipo cliente sino que se accede a través de un navegador que puede ser IE o FireFox, este acceso se realiza a través de una URL como si fuese una aplicación web.
una aplicación XBAP ya hemos dicho que no se instala en el equipo del cliente sino que se almacena en la cache y se ejecuta, si cambia la versión del servidor la copia de la cache se reemplaza por la nueva versión antes de ejecutarse, con lo que la instalación es automática y nos olvidamos de ella.
Las aplicaciones XBAP se ejecutan en una sandbox bajo partial trust, en otras palabras se permite el acceso a ciertas librerías de .NET pero a otras no que en WPF son accesibles , realmente los permisos son como una aplicación InternetZone. En la siguiente lista se indican que objetos están permitidos y cuales no
Permitidos
- UI Controls
- Text Input controls (incluido RichTextBox).
- Flow documents y lectores
- XPS documents
- 2D drawing
- 3D
- Animation
- Audio
- Video
- Pages
- MessageBoxes
- OpenFileDialog
- Internal Drag and drop
- llamadas a WCF services.
- llamadas a ASMX services.
No Permitidos
- Venatanas Stand-alone .
- Dialogos Estandars.
- Interop con controles windows o ActiveX.
- Bitmap Effects
- Shader Effects
Al estar en una InternetZone tienen ciertas operaciones restringidas, en el siguiente cuadro se muestra la lista de permisos de una aplicación XBAP
Como veis solo tiene activos 7 permisos, los demás permisos son denegados.
Así que no elijáis tan alegremente que es mejor una aplicación XBAP porque se puede acceder desde cualquier sitio
Muchas veces me preguntan las diferencias que hay entre el clásico ejecutable que generamos con WPF y
Bueno, la decisión entre XBAP y FullTrust no es tanto tanto la facilidad de acceso desde cualquier sitio, ya que puedes desplegar una app con ClickOnce y salvo un click más de instalación tienes las mismas capacidades de instalación y actualización automática a través de una URL.
Sobre las restricciones quiero añadir una matización importante, el uso de WCF está limitado:
– Site of Origin: Solamente se puede invocar a servicios en el origen del XBAP.
– Subconjunto de WCF, al menos en .net 3.5 no estaban incluidos los bindings de transporte no http, ni duplex, ni seguridad a nivel de mensaje….
Más o menos las restricciones que tiene Silverlight, salvo el hecho, que yo sepa, de que no hay forma de habilitar acceso Out Of Origin con un fichero de policies como en Silverlight y Flash
Hola Pablo, en efecto tienes razçon entre Click Once y XBAP la diferencia de instalación no es tanta pero es la razón mas argumentada.
Yo tampoco se si hay forma de habilitar el acceso Out Of Origen y no he encontardo referencias ne ningún sitio sobre ello asi que tiendo a pensar que no hay.
por cierto buenas matizaciones sobre lo de WCF
Hola,
de hecho el archivo.xbap desplegado por nuestra aplicación no es ni más ni menos que un fichero de manifiesto de ClickOnce.
Aunque XBAP no contempla mecanismos de escalada de permisos, al ser este un manifiesto ClickOnce podemos usar los mecanismos de ClickOnce para ejecutar nuestra aplicación como Full-Trust.
Si bien también es cierto que la primera decisión a tomar es esta, si nuestra aplicación necesita ejecutarse en FullTrust deberemos optar por un EXE desplegado por ClickOnce, si no es el caso XBAP es el otro camino.
Saludos