Force the client to update the Silverlight xap file method summary)

Address: http://www.cnblogs.com/jv9/archive/2012/07/17/2595015.html

Http://www.cnblogs.com/yjmyzz/archive/2011/08/07/2130308.html

 

When a new version of Silverlight application is released, the browser cache queries whether the local xap file with the same name already exists and performs simple verification. If the file exists and the verification is the same, the latest version of xap file will be downloaded and updated. We can force the browser to update and download the xap file in the following ways,

 

Method 1. IIS setting

To force the xap file to expire after setting IIS properties, the browser will re-download the xap file as follows:

-Open the IIS manager;

-Open "default website" and find the deployed Silverlight project;

-Find the xap file in the "clientbin" directory;

-Go to the xap properties page and select "HTTP Response Headers ";

 

-In the actions column, select "set common headers ...";

 

-Select "expire web content-immediately" and save the settings.

 

After this setting, when the page is refreshed, the web page content will be forced to expire and the latest xap file will be downloaded to the local device immediately.

 

Method 2: Force update in dynamic mode

The so-called dynamic force update method uses different xap file names for each deployment. Each time the browser detects different file names, it will re-download the xap file.

There are many implementation methods for this method. For example, you can manually add an xap file parameter, dynamically generate a random parameter, or bind it to the xap file name based on different versions.

In the following exampleCodeTo force update the xap file by using the date string as the parameter of the xap file,

Code modification static code" < Param name = " Source " Value = " Clientbin/silverlightapp. xap " /> "For dynamic code, when the project is not in debug mode, a new xap file path is generated.

< Object ID = "Xaml1" Data = "Data: Application/x-silverlight-2 ," Type = "Application/x-silverlight-2"
Width = "100%" Height = "100%" >

<%
String Orgsourcevalue = @ " Clientbin/silverlightapp. xap " ;
String Param;
If (System. Diagnostics. Debugger. isattached)
Param = " <Param name = \ " Source \ " Value = \ "" + orgsourcevalue + " \ " /> " ;
Else
{
String Xappath = Httpcontext. Current. server. mappath (@ "" ) + @ " \ " + Orgsourcevalue;
Datetime xapcreationdate = System. Io. file. getlastwritetime (xappath );
Param = " <Param name = \ " Source \ " Value = \ "" + orgsourcevalue + " ? Ignore = "
+ Xapcreationdate. tostring () + " \ " /> " ;
}
Response. Write (PARAM );
%>
< Param Name = "Onerror" Value = "Onsilverlighterror" />

Method 3: automatically generate a local version number to force update the xap File

This method was proposed by Yang Guo, a netizen under the bodhi tree. The author created a simple local application and used the local application to generate different xap file name parameters. The principle is the same as method 2 and the implementation method is different.

In SL development, projects are usually divided into multiple xap modules for on-demand download. However, due to the browser cache, even if the code of a module has been modified and re-released to the server, if the xap is already in the browser cache, it is still possible to call the local cache instead of the latest version during actual loading.

Usually the solution to this problem is to append a random number after the xap package, like the http://xxx.com/abc.xap? T = 1235817232. However, this is equivalent to forcing the browser to re-download the xap file each time, and the cache mechanism is completely wiped out. Especially for some large projects, xap is usually relatively large and it takes a long time to re-download each time, poor user experience.

A relatively scientific method is to replace "random number" with "version number", such as http://xxx.com/abc.xap? V = 20101001

Update the version number at each release. However, manual work like modifying the version number should be automatically completed by machines, rather than relying on people.

To this end, we first create a tool that automatically generates version numbers: genversion.exe, which is a console application and the code is extremely simple.Using System;
Using System. Io;

Namespace Genversion
{
Class Program
{
Static Void Main ( String [] ARGs )
{
String _ Filename = "Version.txt" ;
If ( ARGs . Length > 0 )
{
_ Filename = ARGs [ 0 ];
}
File . Writealltext ( _ Filename , Datetime . Now . Tostring ( "Yyyymmddhhmmss" ));

}
}
}

Note: The date string is used as the version number.

Bytes

Key: Call $ (projectdir) version \ genversion.exe $ (projectdir) version \ version.txt command.

Note: you cannot update the version. txt file automatically when compiling the version. Check whether the folder has write permission.

The problem solved when the version number is automatically generated. How does SL use the server version number?

The processing logic of the SL loading project is as follows:

1. Check the Client Version Information in the local independent storage (which can also be stored using cookies) and obtain the Client Version Number clientversion.

2. Then go to the service version.txt to get the server version number serverversion.

3. Compare the two version numbers, declare a variable, take the maximum value of the two version numbers, and save them in maxversion.

4, when loading the main module xap package, with similar http://www.xxx.com/SL_App.xap? V = maxversion URI Loading

5. After the download is complete, save the maxversion to local independent storage (or cookie) to facilitate next comparison.

The above ideas not only apply to processing xap On-Demand Loading, but also to cache data in independent storage, sometimes we save some infrequently updated data in the form of files on the client as the data cache, and we also encounter version update problems.

The solution is simple:

Similar to the above practice, the version number is recorded in the first line of the cache file, and the server version number is compared before the local cache is called. If the server version is updated, the local cache is updated, otherwise, use the local cache directly.