Windows Presentation Foundation XAML Browser Applications Overview
XAML browser applications (XBAPs) combines features of both Web applications and rich-client applications. Like Web applications, XBAPs can be published to a Web server and launched from Internet Explorer. Like rich-client applications, XBAPs can take advantage of the capabilities of WPF. Developing XBAPs is also similar to rich-client development. This topic provides a simple, high-level introduction to XBAP development and underscores where XBAP development is different than standard rich-client development.
This topic contains the following sections.
- Implementing a XAML Browser Application (XBAP)
- Deploying a XAML Browser Application
- XBAP Security Considerations
- XBAP Start Time Performance Considerations
Implementing a XAML Browser Application (XBAP)
The simplest way to create a new XBAP project is with Microsoft Visual Studio:
On the File menu, point to New, and then click Project.
In the New Project dialog box, in the Project types pane, choose either Visual Basic or Visual C#. In the Templates pane, click WPF Browser Application.
Assign a project name and click OK to create the new project.
The WPF Browser Application project template creates an XBAP application project that includes the following:
An application definition, Application.xaml.
A page, Page1.xaml.
You can add to those as required.
If you prefer developing with tools that require command-line compilation, see Building a WPF Application (WPF).
When you run an XBAP, it is launched in a browser window instead of a standalone window. When you debug an XBAP from Visual Studio, the application runs with Internet zone permission and will consequently throw security exceptions if those permissions are exceeded. For more information, see Building a WPF Application (WPF).
Deploying a XAML Browser Application
When you build a XBAP, the Microsoft build engine (MSBuild) produces the following three files as a minimum:
An executable file. This contains the compiled code and has an .exe extension.
An application manifest. This contains metadata associated with the application and has a .manifest extension.
A deployment manifest. This file contains the information that ClickOnce uses to deploy the application and has an .xbap extension.
You publish XBAPs to a Web server (Microsoft Internet Information Services (IIS) or later). You do not need to install .NET Framework on the Web server, but you do need to register the WPF Multipurpose Internet Mail Extensions (MIME) types and file extensions. See How to: Configure IIS 5.0 and IIS 6.0 to Deploy WPF Applications for details.
To prepare your XBAP for deployment, copy the .exe and the associated manifests to your Web server. Create a hyperlink on a Web page to navigate to the deployment manifest. When the user clicks the link and navigates to the .xbap file, ClickOnce automatically handles the mechanics of downloading and launching the application.
Clearing Cached XBAPs
In some situations after rebuilding and launching your XBAP, you may find that a previous version of the XBAP is launched. This may happen, for example, when your XBAP assembly version number is static and you launch the XBAP from the command line. In this case, because the version number between the cached version (the version that was previously launched) and the new version remains the same, the new version of the XBAP is not downloaded; instead, the cached version is loaded.
In these situations, you can remove the cached version by using the Mage command (installed with the Windows SDK) from the command prompt:
Mage.exe -cc
This ensures that the latest version of your XBAP is launched, because a cached version can't be found. If you debug using Visual Studio 2005, by pressing F5, the latest version of your XBAP should be launched.
In general, you should update your assembly version number with each build.
XBAP Security Considerations
XBAPs must execute within a partial-trust security sandbox that is restricted to the Internet zone permission set. Consequently, your implementation must support the subset of WPF elements that are supported in the Internet zone (see Windows Presentation Foundation Security).
When you host the WebBrowser ActiveX control (WebOC) in the Internet Explorer browser process, the following security limitations apply.
Internet Explorer blocks modal dialog boxes from the DHTML alert function and ActiveX controls hosted in HTML. Internet Explorer suppresses dialog boxes that originate from threads other than the active tab’s thread.
Hosting the WebOC control raises an exception when an XBAP is loaded cross-domain in an HTML page.
XBAP Start Time Performance Considerations
An important aspect of XBAP performance is its start time. If an XBAP is the first WPF application to load, the cold start time can be ten seconds or more. This is because the progress page is rendered by WPF, and both the CLR and WPF must be cold-started to display it.
Starting in .NET Framework 3.5 SP1, XBAP cold-start time is mitigated by displaying an unmanaged progress page early in the deployment cycle. The progress page appears almost immediately after the application is started, because it is displayed by native hosting code and rendered in HTML.
In addition, improved concurrency of the ClickOnce download sequence improves the start time by up to ten percent. After ClickOnce downloads and validates manifests, the application download starts, and the progress bar begins to update.
Change History
Date |
History |
Reason |
|---|---|---|
July 2008 |
Added section on XBAP start time performance. |
SP1 feature change. |