If you are developing a Silverlight Application before long you are eventually going to run into caching, updating, deployment issues. What do I mean? You update your SL application, perform some internal debugging/testing, chase your tail to figure out why you are not seeing the updates. Lets say you understand what the issue is, resolve it, then proceed to deploy your SL application. You get a few complaints from the test team, hey, where are the updates you promised in the release? Even better yet, the complaint comes from the client. Do you I have your attention yet?

The first issue is not a big deal, easy fix, clear your browser cache and/or setup your ASP.NET page containing the SL control not to be cached by ASP.NET. That will resolve your internal debugging and testing problems. However, this can be come cumbersome. The real issue is once the SL application is downloaded to the client you do not want to keep downloaded it on every request ( by design ). If downloaded on every request you loose the benefit of running on the client. You need to be able to force the SL application to ONLY be downloaded on a change. Greg Duffield outlines a few options to prevent the caching of the XAP file:

1. Using Query String parameters on the source of the xap file. This will only work if you are using absolute Uri’s and if you are not using the asp:silverlight asp.net control to set the parameters.
2. Using a custom HTTP Handler to stream the zap file to the client. Then I have full control, but this just does not feel right.
3. Tell IIS not to cache the page/control. The problem with this while it will give the updated XAP file you lose the benefit of already having the XAP on the client, as they have to download this every time.
4. Serve the scripts off a folder with a version number in its path. That is if a page, index.aspx contained an ASP.NET component, it would load scripts from a path like ~/RadControls/RadXXX/Scripts/2.3.4/SomeScript.js. Whenever you upgrade to a newer version, the 2.3.4 part changes to 3.3.4 or something else, and browsers fetch the new version. You can do the same for your XAP files. The problem with this is maintenance, folder growth, and having to update the path in the page containing the SL driver.

The simplest, most effective, maintenance free solution I found on the web was suggesting to trick the browser into thinking the path to the XAP file changed. We can automate the file path changing each time the XAP file timestamp changes by using a version query string variable as seen below. A word of caution, this works fine for me running Silverlight 3 and IE6,7,8 but there have been posts indicating this did not resolve the issue. This is the BEST solution I’ve seen to date.

1
2
3
4

<param name="source" value="<%=String.Format("{0}?v={1}",
"ClientBin/MySmaple.SL.xap",
System.IO.File.GetLastWriteTime(
Server.MapPath("ClientBin/MySample.SL.xap")).ToBinary()) %>"/>