Search This Blog

December 17, 2012

Simple Solution- force browsers to reload Silverlight .xap in user's machine for the specific Production Release


I wrote the post on July 17, 2012 entitled Silverlight .xap needs to be updated in the users’ laptops after pushing a new build. But recently we noticed that .xap file is not updated in user’s machines after we push new change to Production.

The quick workaround for them is to clear the caches in their local machines and hitting the site again will download the latest .xap and .zip files. However, it is not user-friendly.

That being said, we need to force browsers to reload Silverlight .xap in user's machine after we push to Production. Silverlight .xap versioning seems a good idea. 

Actually, I have one simple solution: using different .xap name for the specific Production release. For example, if we have the 12/17 release, we can use XXX1217.xap as the naming convention.

When I use TFS to merge the code from DEV Branch to TEST branch, I can modify the following settings for our Jan 10 release, 2013.

Default.aspx:

Before- param name="source" value="ClientBin/Sprint2.xap"

After - param name="source" value="ClientBin/SprintJan10.xap"

Unload Project and Edit Project file.

Before – XapFilename>Sprint2.xap

After -   XapFilename>SprintJan10.xap

In ClientBin folder, I delete Sprint2.xap first.  After building the solution successfully, I can see sprintJan10.xap in ClientBin Folder. After pushing a new TFS build, the build is successful. When I hit Silverlight Application and check the following folder, SprintJan10.xap is really there.

%USERPROFILE%\AppData\Local\Microsoft\Windows\Temporary Internet Files\



Next time if users have the issue, it is really for me to know if they have the specific Silverlight .xap file for our specific release.


No comments: