What you should know about ClickOnce deployment

During past couple months I had a chance to work on ClickOnce deployment in WPF and I have started reading many articles on this topic. These are couple of must know details about ClickOnce that I am going to share here.

How ClickOnce Performs Application Updates

ClickOnce uses the file version information specified in an application's deployment manifest to decide whether to update the application's files. After an update begins, ClickOnce uses a technique called file patching to avoid redundant downloading of application files.

File Patching

When updating an application, ClickOnce does not download all of the files for the new version of the application unless the files have changed. Instead, it compares the hash signatures of the files specified in the application manifest for the current application against the signatures in the manifest for the new version. If a file's signatures are different, ClickOnce downloads the new version. If the signatures match, the file has not changed from one version to the next. In this case, ClickOnce copies the existing file and uses it in the new version of the application. This approach prevents ClickOnce from having to download the entire application again, even if only one or two files have changed.

File patching also works for assemblies that are downloaded on demand using the DownloadFileGroup and DownloadFileGroupAsync methods.

Compiling using Visual Studio

If you use Visual Studio to compile your application, it will generate new hash signatures for all files whenever you rebuild the entire project. In this case, all assemblies will be downloaded to the client, although only a few assemblies may have changed.

Data Exceptions

File patching does not work for files that are marked as data and stored in the data directory. These are always downloaded regardless of the file's hash signature. For more information on the data directory, see Accessing Local and Remote Data in ClickOnce Applications.

Size Limitations

A single partially-trusted, online application is limited to occupying half of the quota space. Installed applications are not limited by the cache size and do not count against the cache limit. For all ClickOnce applications, the cache retains only the current version and the previously installed version.

By default, client computers have 250 MB of storage for online ClickOnce applications. Data files do not count toward this limit. A system administrator can enlarge or reduce this quota on a particular client computer by changing the registry key, HKEY_CURRENT_USER\Software\Classes\Software\Microsoft\Windows\CurrentVersion\Deployment\OnlineAppQuotaInKB, which is a DWORD value that expresses the cache size in kilobytes. For example, in order to reduce the cache size to 50 MB, you would change this value to 51200.

Choosing an Update Strategy

There are three basic strategies that you can use:

- checking for updates on application startup

- checking for updates after application startup (running in a background thread)

- providing a user interface for updates

Providing a User Interface for Updates

Using this strategy, the application developer provides a user interface that allows the user to choose when or how often the application will check for updates. For example, you might provide a "Check for Updates Now" menu item, or an "Update Settings" dialog box with choices for different update intervals. The ClickOnce deployment APIs (System.Deployment.Application namespace) provides a framework for programming your own update user interface.

Permission Elevation and Updates

 If a new version of a ClickOnce application requires a higher level of trust to run than the previous version, ClickOnce will prompt the user, asking him if he wants the application to be granted this higher level of trust. If the user declines to grant the higher trust level, the update will not install. ClickOnce will prompt the user to install the application again when it is next restarted. If the user declines to grant the higher level of trust at this time, and the update is not marked as required, then the old version of the application will run. If the update is required, however, then the application will not run again until the user accepts the higher trust level.

Downloading Assemblies on Demand with the ClickOnce Deployment API

By default, all of the assemblies included in a ClickOnce application are downloaded when the application is first run. You might, however, have parts of your application that are used by a small set of your users. In this case, you want to download an assembly only when you create one of its types. You can mark certain assemblies in your application as "optional", and download them by using classes in the System.Deployment.Application namespace when the common language runtime demands them.

Assembly Binding Redirection

You can redirect an assembly binding reference to another version of an assembly by using entries in the application or machine configuration files. You can redirect references to .NET Framework assemblies, third-party assemblies, or assemblies of your own application.

When you build a .NET Framework application against a specific version of a strong-named assembly, the application uses that version of the assembly at run time. However, sometimes you might want the application to run against a newer version of an assembly. An application configuration file, machine configuration file, or a publisher policy file can redirect one version of an assembly to another.

You can use the .NET Framework Configuration tool (Mscorcfg.msc) to redirect assembly versions at both the application level and the machine level, or you can directly edit the configuration file.

Note : You cannot redirect versions for assemblies that are not strong-named. The common language runtime ignores the version for assemblies that are not strong-named.

Comments

• Anonymous
  July 21, 2010
  This is a superb article. Unfortunately, it didn't help me yet to figure out why my deployments work great on my machine, but fail on every Win7 or XP system around, with different failures, but zero bytes in the install logs, so I'm a bit blind as to what's going on. This article might provide me some info to sleuth out the issues, however. Bob