Problem: ClickOnce Deployment via Internet May Not Always Upgrade an Application

• Download source - 226.22 KB

Introduction

An application deployed using ClickOnce may not receive an upgrade if the browser's proxy server has cached an older deployment file. This article explains how to solve this problem using HTTP content expiration.

Background

Let's assume you have deployed an application, called TestAppForClickOnce, via ClickOnce on a host Website. The metadata file named TestAppForClickOnce.application is the primary download artifact for clients to install this application.

The default expiration settings on the host Website (using IIS) will cause TestAppForClickOnce.application to have no expiry. Depending on what type of firewall is used in the client network, a copy of TestAppForClickOnce.application will be cached there after the client browser downloads this file. Subsequent requests from the same browser or any other browsers using the same proxy settings, will receive the cached copy of that file.

A new version of TestAppForClickOnce may be hosted on the host Website and this is done using a new version of TestAppForClickOnce.application. The client upgrade is triggered during application launch or by the user accessing the TestAppForClickOnce.application directly from the host Website. Since TestAppForClickOnce.application is not interpreted as dynamic content, the cached version is passed to the client browser and a new version of the file will not be downloaded from the host Website. This means some clients will not receive your version upgrade.

Depending on conditions within the firewall, the TestAppForClickOnce.application file may be dropped from the cache and this inadvertently allows the new application version through. However, this does not present a good solution because it is not clear how long the new application version will remain inaccessible.

Using the Code

Solution: Explicitly set expiry of all ClickOnce deployment files.

Since cached ClickOnce deployment files present a big problem for upgrades, a solution is offered here. The primary solution is to explicitly set the expiry of ClickOnce deployment files. The detailed solution below chooses to set the expiry to "immediate" and implements this expiry using the Web.config file within a .NET 2.0 Website. You may also use IIS to set the expiry of each file in a Website but not all Web hosting providers have this option available. Other Web hosting technologies offer alternative expiry implementations, but they are not covered in this solution.

Step 1: In the Web.config file, add an HTTP handler.

<?xml version="1.0"?>
<configuration>
<location path="Downloads">
<system.web>
<httpHandlers>
<add verb="*" path="*.*" type="CustomHttpHandlers.ClickOnceApplicationHandler"/>
</httpHandlers>
</system.web>
</location>
…

Step 2: Create a class named ClickOnceApplicationHandler with namespace CustomHttpHandlers.

Step 3: Make ClickOnceApplicationHandler inherit from IHttpHandler.

Step 4: Implement the ProcessRequest members.

void IHttpHandler.ProcessRequest(HttpContext context)
{
context.Response.Cache.SetExpires(DateTime.Now);
context.Response.Cache.SetValidUntilExpires(true);
context.Response.Cache.SetCacheability(HttpCacheability.NoCache);
string path = context.Server.MapPath(context.Request.Path).ToLower();
if (File.Exists(path))
{
//Ensure browser handles application files correctly
if (path.EndsWith(".application")) context.Response.ContentType =
        "application/x-ms-application";
byte[] outputBinaryArray;
FileStream fs = new FileStream(path, FileMode.Open, FileAccess.Read);
BinaryReader r = new BinaryReader(fs);
outputBinaryArray = r.ReadBytes(Convert.ToInt32(fs.Length));
r.Close();
fs.Close();
context.Response.BinaryWrite(outputBinaryArray);
}
else
{
throw new HttpException(404, "File not found");
}
}

Conclusion

What This Solution Has Achieved

The above solution ensures that well-behaved firewalls do not cache ClickOnce deployment files.

What This Solution Does Not Achieve

If a firewall server has already cached any ClickOnce deployment files, the above solution does not expire them. When a file is cached, the firewall does not retrieve a new copy from the host Website and therefore the original expiration settings remain. In this case, the firewall cache needs to be manually purged, but most often this cannot be done by authors of the host Website.

My advice is to implement the above expiration solution as soon as possible to ensure none of your customers get affected by cached ClickOnce files.

To test some ClickOnce applications using the above caching solution, visit Coded Silicon.

Caveat

One caveat that makes this solution less independent from IIS settings is that IIS does not by default map .application files to ASP.NET.
So to make this solution work, you still need to change the settings in IIS.

The change in settings is as follows:
In the application mapping properties, add a mapping for .application to run using
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
(Path may be different on your server).

So if you had to tweak the settings in IIS, why not set the expiration settings directly in IIS (under HTTP Headers)?
Setting the expiration settings directly in IIS is a viable quick solution, but using an HTTP handler provides better control over caching. The HTTP handler solution allows us to selectively modify the cache settings of .application files only or to selectively modify the cache settings of the files in a particular folder.

History

• 15^th October, 2007 -- Original version posted
• 25^th October, 2007 -- Caveat added