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

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 namedTestAppForClickOnce. applicationIs the primary download artifact for clients to install this application.

The default expiration settings on the host Website (using IIS) will causeTestAppForClickOnce. applicationTo have no expiry. Depending on what type of firewall is used in the client network, a copyTestAppForClickOnce. applicationWill 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 versionTestAppForClickOnce. application. The client upgrade is triggered during application launch or by the user accessingTestAppForClickOnce. applicationDirectly from the host Website. SinceTestAppForClickOnce. applicationIs 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,TestAppForClickOnce. applicationFile 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 explain itly set the expiry of ClickOnce deployment files. the detailed solution below chooses to set the expiry to "immediate" and implements this expiry usingWeb. configFile within. 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.

Collapse | Copy Code

<?xml version="1.0"?><configuration><location path="Downloads"><system.web>
Step 2: Create a class namedClickOnceApplicationHandlerWithnamespace CustomHttpHandlers.
Step 3: MakeClickOnceApplicationHandlerInherit fromIHttpHandler.
Step 4: ImplementProcessRequestMembers.
Collapse | Copy Code
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 correctlyif (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");}}
ConclusionWhat This Solution Has Achieved
The above solution ensures that well-behaved firewils 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 MERs 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. ApplicationFiles 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. ApplicationTo 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. ApplicationFiles only or to selectively modify the cache settings of the files in a participant folder.
 
Http://www.codeproject.com/Articles/20873/Problem-ClickOnce-Deployment-via-Internet-May-Not