The Avalon deployment story

For a long time, application developers have struggled with building web applications that also have a rich, immersive user experience that leverages the capabilities of the OS and the hardware. By providing a single managed code framework for controls, media and animation, 2D-3D images and graphics, and an application UI rendered on a vector-based composition engine, Avalon makes for a powerful development platform for the presentation tier. It combines the best of breed from both browser-based and rich-client Windows applications. And backed by a rich API set, it lets you do cool stuff ... faster.

Avalon UI is typically implemented in the XAML declarative markup language where each tag maps to an underlying control. The platform provides for a very clear separation of UI from the backing code.

A lot of our customers do not understand security nitty-gritty’s. And there is little reason they should. As software developers, it is our job to create runtimes and applications that abstract this from customers and make their deployment and activation experience as painless as is humanly possible, in the most secure environment possible. That being the guiding principle, Avalon provides for two flavors of applications: Express or browser-hosted applications and Installed or standalone window-based applications running with full trust.

The Avalon Express applications were conceived to do exactly this. As browser hosted applications, Avalon Express apps run in a partial trust environment: meaning they are sandboxed and do not enjoy all of the privileges of a traditional installed application on Windows. The Express app's trustworthy deployment model enables users to download and execute applications over the Internet without requiring administrator privileges on the client machine. This 'ClickOnce' deployment model prevents deployed applications from interfering with or corrupting other applications or data on the client machine.

The choice of application flavor is registered in the project file. We’ve kept this very simple. If you were building an Express application, you’d declare:

    <HostInBrowser>true</HostInBrowser>

in the project file. Alternatively, an Installed application requires the declaration:

    <Install>true</Install>

When one of these isn’t specified, its default value is considered false. Of course, HostInBrowser and Install cannot (currently) have the same value. You are probably aware that IE 4.0 and onwards provide users with a set of templates that they can use to determine the level of security they want for a particular URL security zone. For any Avalon application, you can specify the zone value such that when the apps are run, their permissions are limited to the zone template chosen. Typically, Express apps run in the Internet zone (i.e. the Medium zone template) and Installed apps run in the Local Machine zone (i.e. the Low zone template for highly trusted applications).

Now, suppose you were building an Express application called “Bumper”. If you’ve specified the right project properties, your build output folder should have these files created:

• Bumper.xapp


• Bumper.exe


• Bumper.exe.manifest

Here, Bumper.xapp is the deployment manifest.

Likewise, if you were building an Installed application called “Pixie”, you’d have these files created:

• Pixie.application


• Pixie.exe


• Pixie.exe.manifest

In this case, Pixie.application is the deployment manifest.

You can then publish the files onto the deployment server (a network location or a web server) and provide a URL link to the deployment manifest. When a user clicks on that link, the WinFX runtime on that system will recognize that extension and trigger a ClickOnce deployment, download and activation of the application on the user’s machine. The files are downloaded to a cache at an obfuscated location on the user’s machine. The application runs with the security context determined by the target zone specified.

One notable incident at deployment occurs when the user clicks on the link to the Express application’s deployment manifest. At this time the WinFX runtime will check the version cached locally against the version on the deployment server. If the latter is a newer version, then the newer files are downloaded before activation. Avalon Installed applications have Start menu and Add/Remove Programs (ARP) presence. Update checks for Installed applications are therefore a little more complicated. And with a set of APIs to customize the update behavior, ClickOnce delivers a pretty potent auto-update feature, available out of the box in all WinFX applications.

In order to further secure the end-user’s experience with Avalon (or WinFX) applications, we have recently turned on enforcement of deployment provider (where the app was launched from) and manifest signature validations at runtime. A future release of WinFX will carry these changes. Consequently, when the user clicks on the link to the deployment manifest, the WinFX runtime will parse the manifest and validate these two rules and only on success will the application be executed.

I use the term Avalon and WinFX interchangeably. Actually Avalon, like Indigo, is one of the chief components of the WinFX Runtime Components. Also, all Avalon applications are WinFX applications. But the reverse is not necessarily true. You can build a WinForms based WinFX application (an Installed application flavor) with no Avalon present in it.

Tags: WinFX

Email this | Bookmark this