Internet Deployment of Windows Applications

The earlier discussions of creating an installation package for your application presumed that you were able to transfer the MSI file to each machine that needed installation, either electronically or via some storage medium such as a CD-ROM. This works well for installations within an organization and can work acceptably for initial installation from CD-ROMs on distributed systems.

However, the availability of the Internet has raised the bar for acceptable deployment of Windows-based client applications. Perhaps the most important advantage of browser-based applications has been their ease of deployment for the user. For Windows Forms applications to be cost-competitive with browser-based applications, low-cost deployment over the Internet is needed.

Fortunately, there are several ways to get low-cost deployment over the Internet, including the following:

• “No-touch” deployment

• Deployment with ClickOnce, a capability added to Visual Studio 2005

• Components or libraries that contain deployment capabilities, such as the Application Updater Application Block

Different deployment techniques are suitable for different applications. This section looks at each technique and discusses how it works and what kinds of applications it is suitable for use with.

No-Touch Deployment

Built into all versions of the .NET Framework is the capability to run applications from a Web server instead of from the local machine. There are two ways to do this, depending on how the application is launched.

First, an application EXE that exists on a Web server can be launched via a standard HTML hyperlink. An application named MyApp.exe that is located at www.mycompany.com/apps can be launched with the following HTML in a Web page:

 <a href="http://www.mycompany.com/apps/MyApp.exe">Launch MyApp</a>

When the hyperlink is clicked on a system with the .NET Framework installed, Internet Explorer transfers control to the .NET Framework to launch the program. The framework then tries to load the EXE assembly, which does not yet exist on the client. At that point, the assembly is automatically fetched from the deployment Web server and placed on the local client machine. It resides on the client machine in an area called the application download cache, which is a special directory on the system managed by the .NET. Framework.

If the EXE tries to load a class from another application assembly (typically a DLL), then that assembly is assumed to be in the same directory on the Web server as the EXE. The application assembly is also transferred to the application download cache and loaded for use.

This process continues for any other application assemblies that are needed. The application is said to trickle-feed to the client system.

Automatic Updating

Whenever an assembly in the application download cache is needed, the .NET Framework automatically checks for a new version in the appropriate directory on the Web server. Thus, the application can be updated for all client machines by simply placing an assembly on the Web server.

Using a Launch Application

One drawback of this technique for deploying the application is that it can only be launched from a Web page or other means of accessing a URL (such as a shortcut or the Start Run dialog).

To get around this limitation, you can get a similar deployment capability by using a small launching application that uses dynamic loading to start the main application. Dynamic loading was discussed in the previous chapter. In this case, the location for the assembly used in dynamic loading will be the URL of the assembly on the Web server.

An application that uses this technique still gets all the trickle feeding and auto-update features of an application launched straight from a URL.

Limitations of No-Touch Deployment

No-touch deployment is useful for simple applications, but has some serious drawbacks for more complex applications:

• An active Internet connection is required to run the application - no offline capability is available.

• Only assemblies can be deployed via no-touch deployment - application files such as configuration files cannot be included.

• Applications deployed via no-touch deployment are subject to code-access security limitations, as discussed in Chapter 12.

• No-touch deployment has no capability to deploy any prerequisites for the application or any COM components that it may need.

Given the limitations of no-touch deployment, Microsoft has added an alternative to the .NET Framework 2.0 called ClickOnce. It is essentially a complete replacement for no-touch deployment. Thus, while no-touch deployment is still supported in .NET Framework 2.0, it is no longer recommended for use, and is not discussed further.

ClickOnce Deployment

A more advanced form of Internet and network deployment uses a new technology in .NET Framework 2.0 called ClickOnce. It is intended to overcome the limitations of no-touch deployment and to provide a robust, easy-to-implement deployment option for a wide range of applications.

ClickOnce has several advantages over alternatives such as no-touch deployment, including the following:

• Updating from a Web server with user control - No-touch deployment only allows completely automatic updating from the Web server. ClickOnce can be configured for completely automatic updates from a Web server, but it can also be set up to allow more control by the user over when the application is installed and uninstalled.

• Offline Access - Applications deployed with ClickOnce can be configured to run in an offline condition too. Applications that can be run offline have a shortcut installed on the Start menu.

ClickOnce also has advantages over applications installed with Windows Installer. These include auto-updating of the application from the deployment server, and installation of the application by users who are not administrators. (Windows Installer applications require the active user to be an administrator of the local machine. ClickOnce applications can be installed by users with reduced permissions.)

ClickOnce deployment can be performed from a Web server, a network share, or read-only media such as a CD-ROM or DVD-ROM. The following discussion assumes you are using a Web server for deployment, but you can substitute a network share if you do not have access to a Web server.

Important 

ClickOnce does not require the .NET Framework 2.0 or 3.0 to be installed on the Web server you use for ClickOnce deployment. However, it does require that the Web server understand how to handle files with extensions .application and .manifest. The configuration for these extensions is done automatically if the .NET Framework is installed on the Web server. However, on servers that do not contain the framework, you will probably have to do the configuration manually. Each extension that a Web server can handle must be associated with an option called a MIME type that tells the Web server how to handle that file extension when serving a file. The MIME type for each extension used by ClickOnce should be set to application/x-ms-application. If you do not know how to configure MIME types for your Web server, ask a network administrator or other professional who can.

Configuring an Application for ClickOnce

For a simple case, no special work is needed to prepare a typical Windows application to be deployed via ClickOnce. Unlike the deployment options discussed earlier, it is not necessary to add additional projects to the solution. If you use standard options in ClickOnce, it is also unnecessary to add any custom logic to your application. All the work to enable ClickOnce deployment for an application can be performed by selecting options in the IDE.

It is possible to control the ClickOnce deployment by writing your own custom logic controlling the ClickOnce deployment processes. However, that capability is beyond the scope of this book and is not discussed here. Instead, this chapter covers basic configuration of ClickOnce and common options that do not require you to write any code.

Online vs. Locally Installed Applications

Applications installed via ClickOnce are one of two types:

• Online applications, which can only be accessed by the user when the system has a connection to the website used to deploy the application

• Offline applications, which can also be used when there is no connection available

Online applications must be launched with a URL (Uniform Resource Locator), a standard filename, or a UNC (Universal Naming Convention) filename. This may be done in various ways, such as clicking a link in a Web page, typing a URL into the Address text box of a browser, typing a filename into the Address text box of Windows Explorer, or selecting a shortcut on the local machine that contains the URL or filename. However, ClickOnce does not automatically add any such mechanisms to a user’s machine to access the application. That is up to you.

Offline applications can also be launched with a URL or UNC, and are always launched that way the first time. The differences are as follows:

• When ClickOnce does the initial installation of the application on the user’s machine, by default it places a shortcut to the application on the user’s Start Programs menu.

• The application can be started from the shortcut, and will run with no connection to the original location used for installation. Of course, any functionality of the application that depends on a network or Internet connection will be affected if the system is not online. It is your responsibility to build the application in such a way that it functions properly when offline.

Deploying an Online Application

A walk-through of deployment for a simple Windows application will demonstrate the basics of ClickOnce. This first walk-through deploys an online application to a Web server, which is one of the simpler user scenarios for ClickOnce.

First, create a simple Windows Application in Visual Studio, and name it SimpleApp. On the blank Form1 that is created as part of the application, place a single button.

To enable ClickOnce deployment, access the Build menu and select the Publish SimpleApp option. The ClickOnce publishing wizard will appear. The first screen in the wizard is shown in Figure 22-17.

Figure 22-17

The location will default to a local Web server, but as discussed earlier, deployment can be done to a network share or even a local directory. Change the location if the default is not appropriate for your circumstances. Once you’ve verified the location to publish, click Next.

Select one of the two types of ClickOnce applications discussed earlier. Because this example is for an online application, click the second option to make the application only available online (see Figure 22-18).

Figure 22-18

Click Next to see a summary of your selection, and then click Finish. The ClickOnce deployment process will begin. A new item called SimpleApp_TemporaryKey.pfx will be added to your project, a complete build will be done, a new virtual directory will be created for the application on the Web server, and the files needed to deploy the application will be copied to that virtual directory. (The new item is discussed in the section “Signing the Manifest.”)

When the process is complete, a Web page will be generated that contains the link needed to deploy the application. The Web page will have a Run button that activates the link. If you click this button, the application will be deployed by ClickOnce. (You may wish to view the source for this Web page to obtain the HTML needed to launch the application from your own Web pages.)

First, the prerequisites for the application are verified. In this case, that just means the .NET Framework. Next, a Security Warning dialog is displayed, asking whether it is acceptable to run the application, as shown in Figure 22-19. You can run the application by clicking Run, or click Cancel, which aborts the process. Click the Run button, and after a short delay you will see the application’s form appear.

Figure 22-19

If you now make any changes to the SimpleApp application, you must publish the application again to make the changes available via ClickOnce. You can do that by stepping through the publishing wizard once again. More about automatic updating of ClickOnce applications is discussed later in the section “The Update Process.”

Deploying an Offline Application

In the second screen of the publishing wizard, if you select the first option, then the installation process has some differences:

• The Web page that ClickOnce generates to test the deployment will have an Install button instead of a Run button.

• When the button is pressed, a shortcut to the application is added to the user’s Start Programs menu. The shortcut will be in the program folder named for the company name that was entered when Visual Studio was installed.

• The application is launched at the end of the install process, as it was with an online app, but future launches can be accomplished with the same URL or via the shortcut in the Start menu.

Files and Directories Produced by ClickOnce

The virtual directory used by ClickOnce to deploy your application contains a number of files for different aspects of the deployment. Figure 22-20 shows what the directory for SimpleApp looks like after ClickOnce has finished copying all needed files.

Figure 22-20

The virtual directory contains a folder for the first version of SimpleApp, which by default is version 1.0.0.0. It also contains the Web page that is displayed after ClickOnce finishes, named publish.htm.

The next file is Setup.exe. This is an executable that does not need the .NET Framework to run. It is used during the ClickOnce process for all the activities that must take place before the application is launched, including activities such as checking for the presence of the .NET Framework. It is discussed further in the section “The Bootstrapper.”

The next file is SimpleApp.application. The “.application” extension is specific to ClickOnce, and indicates a special file called a manifest. This is an XML-based file that contains all the information needed to deploy the application, such as what files are needed and what options have been chosen. There is also a file named SimpleApp_1_0_0_0.application, which is the manifest specifically associated with version 1.0.0.0.

Each version of the application has its own manifest, and the one named SimpleApp.application (with no embedded version number) is typically the currently active one. (Thus, the link to the application does not need to change when the version number changes.) Other files associated with a version are in the folder for that version.

Signing the Manifest

Because the manifest controls the update process, it is essential that ClickOnce be assured that the manifest is valid. This is done by signing the manifest, using a public-private key pair. As long as a third party does not have the key pair, that party cannot “spoof” a manifest, preventing any malicious interference in the ClickOnce deployment process.

A key pair is automatically generated when you publish with ClickOnce. However, you can supply your own key pair if you like. Options for signing the application are discussed in the section “ClickOnce Configuration Options.”

Note that your application assemblies do not need to be signed for them to be used in a ClickOnce deployment. Only the manifest needs to be signed. The manifest contains hash codes of all the assemblies involved, and those hash codes are checked before assemblies are used. This prevents malicious third parties from inserting their own versions of your assemblies.

The Update Process

By default, all ClickOnce applications check for updates each time the application is launched. This is done by getting the current version of the manifest and checking whether any changes have been made since the last time the application was launched. This process is automatic, so there’s nothing you need to do to make it happen, but it’s helpful for you to understand the steps that are taken.

For an online application, when a change is detected, it is immediately applied by downloading any changed files. Then the application is launched. In spirit, this is similar to a browser-based application, because the user does not have any option to use an older version.

For an application available offline, when changes are detected, the user is asked if the update should be made. The user can choose to decline the update. There is a configuration option that enables you to specify a minimum version number, which can force a user to accept an update. We will look at ClickOnce configuration options later.

If an update is made for an offline application, then the previous version is kept. The user then has the capability to rollback to that version using the Add/Remove Programs option in the Control Panel. Users can also uninstall the ClickOnce-deployed application from that same location.

Only one older version is kept. If there are older versions, they are removed when a new version is installed, so that the only versions available at any point in time are the current version and the one immediately before it. If a rollback is made to the immediately preceding version, it cannot be rolled back any further to earlier versions.

You can control the update process by including code in your application that detects when changes have been made, and apply the changes as necessary. As previously mentioned, this chapter does not cover writing such logic. There are samples available in the MSDN documentation for this capability.

ClickOnce Configuration Options

In Visual Studio 2005, the properties for a Windows Application project now include several pages that affect ClickOnce. (You can get to the properties for a project by right-clicking on it in the Solution Explorer and selecting Properties.)

The Signing tab page includes options for signing the ClickOnce manifest. There are buttons to select a particular certificate from a store or a file, or to generate a new test certification for signing. This page also contains an option to sign the assembly that is compiled from the project, but as mentioned above, this is not necessary for ClickOnce to operate.

The Security tab page controls options relating to the code access security permissions needed by the application to run. Because the application is being deployed from a source off of the local machine, if you use ClickOnce, then code access security limitations are in effect, as described in Chapter 12. A typical example of the Security tab page is shown in Figure 22-21.

Figure 22-21

Using the options on the Security tab page, you can calculate the permissions needed by the application, using the button labeled Calculate Permissions. You can also arrange to test your application against a particular set of permissions. To do that, change the default option “This is a full trust application” to the option immediately below it, labeled “This is a partial trust application.” Then select the zone from which the application will be installed. When the application is run by Visual Studio, permission for that zone will be enforced.

All of the other ClickOnce configuration options are on the tab page labeled Publish, shown in Figure 22-22.

Figure 22-22

You can set many options with the Publish page, but here are some of the most important:

Open table as spreadsheet

Property/Option	Purpose	Where to set it on the page
Publish Location	Specifies the virtual directory, network directory, or local directory to which the application will be published by ClickOnce	Text box labeled Publishing Location. (Note that this can also be set in the first screen of the Publish Wizard.)
Installation URL	Specifies the location from which your application will be deployed by users. By default, this is the same as the Publish Location, but may be set to be elsewhere.	Textbox labeled Installation URL.
Install Mode	Selects the online only vs. offline mode for the application.	Option buttons under Install Mode and Settings. (Note that this can also be set in the second screen of the Publish Wizard.)
Publish Version	Sets the version of the application for publishing purposes. ClickOnce requires version changes to properly auto-update the application.	The text boxes under Publish Version. If the check box under those boxes is checked, the publish version will be automatically incremented each time the application is published.
Prerequisites	Specifies the software that must be installed before your application can itself be installed, including elements such as the .NET Framework	The Prerequisites button brings up a dialog box that allows standard prerequisites to be checked. The .NET Framework is checked by default. The dialog also allows you to specify the location for downloading prerequisites. See the section “The Bootstrapper” for more information on prerequisites.
Miscellaneous options	Options for various purposes such as the product name	The Options button brings up a dialog box that allows these options to be set.
Updates	Options that control the update process, including when the application updates (before or after it starts), the minimum version number required, and so on	These options are only available for applications that can run offline. The Updates button brings up a dialog box controlling these options.

The Bootstrapper

Because applications deployed by ClickOnce are a part of the .NET Framework, the .NET Framework must be available on the user’s machine before your application can be installed and run. In addition, your application may require other items such as a database or COM component to be installed.

To provide for such needs, ClickOnce includes a “bootstrapper” that runs as the first step in the ClickOnce process. The bootstrapper is not a .NET program, so it can run on systems that do not yet have the .NET Framework installed. The bootstrapper is contained in a program called Setup.exe, which is included by ClickOnce as part of the publishing process.

When setup.exe runs, it checks for the prerequisites needed by the application, as specified in the Prerequisites options just discussed. If needed, these options are then downloaded and installed. Only when the user’s system contains installed prerequisites does ClickOnce attempt to install and run your Windows application. The MSDN documentation includes more details on configuring and using the ClickOnce bootstrapper.

Manual Editing of ClickOnce Manifests

Sometimes an application manifest created by ClickOnce needs to be manually changed. For example, if the application contains dynamically loaded .NET DLLs (as discussed in the previous chapter), then such DLLs are not automatically included in a ClickOnce manifest.

In creating a manifest for an installation, ClickOnce relies on the compile-time references for the application being deployed. It places any application assemblies that have compile-time references into the manifest.

However, dynamically loaded assemblies do not have a compile-time reference. That means ClickOnce can’t put them in the manifest automatically. If you have dynamically loaded assemblies in your Windows Forms application, then you must add them to the manifest manually.

ClickOnce includes a tool for manual editing of the manifest. Called MAGE.exe, it can be started from the Visual Studio 2005 command prompt. It offers a UI to open a manifest and perform various manual operations upon it. Figure 22-23 shows what it looks like after a manifest is opened and the page for manipulating files in the manifest is selected.

Figure 22-23

MAGE.exe can also be used from the command line, so you can create batch files or Powershell scripts to automate insertion of files in a ClickOnce manifest. A complete discussion of using MAGE.exe is beyond the scope of this chapter, but the help files for MAGE.exe are extensive, and you can find MSDN samples showing its use.

Rolling Back or Uninstalling ClickOnce Applications

In addition to deploying an application for use, ClickOnce also creates the capability to uninstall or rollback applications that are deployed with the offline option. Such applications will have an entry in the Add/Remove Programs section of the Control Panel. That entry offers an uninstall option, and if a rollback version is present, then an option to rollback the last update is available.

Only one level of rollback is available. If multiple updates have been done, the user can only rollback to the most recent one before the current one. Once a rollback is done, no further rollback is possible until another update has been deployed.

ClickOnce vs. Other Deployment Technologies

ClickOnce is a complete replacement for no-touch deployment. However, there are other deployment scenarios for which ClickOnce may not be the ideal solution. For example, ClickOnce can only deploy a per-user installation; it cannot install an application once to be used by all users on the system.

ClickOnce may be used in combination with technologies such as the Windows Installer. If you create .msi files, as discussed earlier in the chapter, you may include them as part of ClickOnce’s bootstrapper process. This is an advanced technique not discussed in this book, but you can learn more about this capability in the MSDN documentation.

For cases in which ClickOnce is not appropriate, you may wish to use more customized deployment technologies. These are discussed next.

Custom Deployment Options

If an application needs deployment capabilities not covered by the technologies discussed so far, it may be necessary to use alternative technologies, or even develop them yourself. For example, you can create a deployment function that checks via a Web service to see when updating needs to take place and that uses FTP to transfer files from a Web server to a client machine.

Updater Application Block

Rather than start from scratch on such deployment/installation technology, you can look at starting points such as the Updater Application Block. Created by Microsoft’s Patterns and Practices Group, the

Updater Application Block can be downloaded from Microsoft’s website. It includes manifest-based checking of modules for updating and background transfer of new modules using the same transfer technology as Windows Update.

You can use the Updater Application Block as is, or customize it for your own needs. For example, you could create a version that allows different classes of users to have different update strategies, so that new updates go out to a select group of users first.