Features of the Longhorn Application Model

The Longhorn application model defines what an application is:

• Its entry points

• Its flow of control ”how to navigate from one page to another

• Its shared state and resources

• Application-wide events

• Its isolation from other applications

The Longhorn application model defines how to deploy and maintain an application:

• Deployment as single or multiple files

• Update, rollback, and administration

The Longhorn application model defines the user s experience with the application:

• Zero-impact installation

• Stand-alone ( Windows -style) or integrated in browser

• Runs online or offline

• Navigation model

Longhorn Web Applications

The Longhorn application model allows you to write a rich application similarly to the way you write today s Web applications. This provides an easy migration path for Web developers, as the code they write is similar to the code for dynamic HTML (DHTML) Web pages. They can (shudder) place markup and script in same file. They can deploy the files for the application to a Web server. The application pages run in the Web browser.

However, the object model for a Longhorn Web-style application is much simpler and far more powerful than DHTML. The application code can use the complete Longhorn presentation layer. Therefore, a Longhorn Web application can use rich client controls, support multimedia and graphics on the page, handle events locally ”basically everything a normal client application might do. In fact, a Longhorn Web application isn t much different from a Longhorn desktop application other than that the files live on a server; a browser typically, but not necessarily , hosts the UI; and the application runs with restricted permissions because the user hasn t installed it on the client system.

Longhorn Desktop Applications

The Longhorn application model also defines how to write desktop applications. A Longhorn desktop application is an application that the user has installed locally. Such applications can run online or offline. Such applications can register with the shell, place icons on the desktop, add shortcuts to the Start menu, and more.

A desktop application can also run in the browser window or in a stand- alone window. In fact, a desktop application can support many features traditionally associated with a Web application, including the following:

• Explicitly define external entry points ”that is, can start on any page

• Share state across pages

• Handle various events, including page navigation events

• Control application flow

• Add/remove entries from a page history/travel navigation log

• Launch application windows

Building a Longhorn Application

To build a Longhorn application, you define the object model for your application. You can define the model programmatically by writing code or declaratively by writing markup in a language called the Extensible Application Markup Language (XAML). You compile your code and/or markup into one or more .NET assemblies, an application manifest file, and a deployment manifest file.

Optionally, you can package your application into a new file format, called a container . The application files in a container can be compressed, encrypted, and digitally signed.

I discuss building a Longhorn application in detail in Chapter 2, but for now the main idea is that building a Longhorn application gives you the application s code, an application manifest that describes all the components that the application uses, and a deployment manifest that tells the system how to install and maintain the application.

Deploying a Longhorn Application

The Longhorn application model provides for easy, cost-effective deployment of your application. In the simplest case, you simply copy the application files to a server. Similarly, installing your application is straightforward and non-impactful.

One option is not to install the application at all. The user can browse to the application manifest on a server and run it. Longhorn incrementally downloads your application and executes it. You get no confirmation demands, no reboot requirements, and no DLL hell. In fact, you do not even need Administrator rights to install or run the application.

Alternatively, the user can browse to the application s deployment manifest on the server and run it. Longhorn incrementally downloads your application, installs it, and executes it. By default, all Longhorn applications run in a limited permission environment called the Secure Execution Environment (SEE).

Applications running in the SEE receive a restricted permission set that is roughly equivalent to the permissions granted to today s applications associated with the Internet zone. An application that requires additional permissions than Longhorn provides by default must request those additional permissions in its application manifest.

The first time the user runs such an application, the Longhorn Trust Manager will evaluate the elevated permission request, notify the user of a suggested risk level associated with granting the application s permission request, and provide a suggested response for that risk level. When the user permits the Trust Manager to grant the application its requested permissions, the Trust Manager records this information. Subsequent executions of the installed application proceed without the security warning.

Today, when you install an application locally, it receives the FullTrust permission set simply because it loads from the LocalComputer zone. Code Access Security (CAS) works differently for Longhorn applications. A local (or installed) application runs under the security policy of the site from which the user downloaded it instead of automatically receiving FullTrust simply because it is installed locally.

When loading an application, its components, and its resources, Longhorn provides evidence to the common language runtime (CLR) security system such as

• Internet zone and site of origin (from the Uniform Resource Identifier [URI])

• Publisher and module name (from the deployment manifest)

CAS then provides security policy “based enforcement over access privileges based on the application s evidence.

The deployment manifest for an application can specify the update interval that Longhorn should use when checking for a new version of the application. When Longhorn detects that a new version is available, it downloads and installs the new version in the background. The next time the user runs the application, she receives the new version.

When installing an application, Longhorn preserves the previous version, if any. Should you need to, you can painlessly roll back to the previous version or even completely uninstall the application using Add/Remove Programs. IT departments can push the installation of an application to a client system for a hands-free deployment.

You specify how to deploy the application when you compile the project, and you can change the deployment scenario by recompiling, typically with few or no changes to your source code.

A developer s program initially interacts with much of Longhorn s application support via an instance of the MSAvalon.Windows.Application class, so let s look at that class.