Automatic update of. Net Applications [reprint]

Author: Li Jia Source: CSDN development expert Editor: Fangzhou

There are two ways to update an application: one is to notify the user (such as sending an email) and let the user download the updated program from the specified website address; the second is to transfer the update responsibility from the user to the application itself, and the application itself replaces the user to obtain and install an update of the software, the client application itself is responsible for downloading and installing updates from a known server. The only thing users need to intervene in is to determine whether they are willing to install new updates now or later. Obviously, the latter is more friendly than the former. Now you can see the actual products like the last method, such as Windows XP and Microsoft Money. The. NET application update component described in this article provides similar functions.

　　1. Introduction to the. NET application update component

AppUpdater, A. NET application update component, is developed using the. NET Framework. Although AppUpdater is not a Microsoft product. you can drag this component from the toolbar to your application, just like using other components, and set some attributes (such as the location and frequency of obtaining updates) so that your client application can be automatically updated.

　　Ii. Working Principle

To thoroughly understand how the. NET client application updates components work, you need to carefully study the things necessary to update the client application. The first step is to check whether there are updates. When an update is found, start the second step-download the update. When the update download is complete, the last step is to implement updates.

(1) Check for updates

As a developer, you must first tell the application where to perform the update check. Otherwise, isn't it a haystack? Next, determine when to perform the update check. It is impossible for the user to run the client program every time, and it will not stop updating and checking in the background, which is a waste of resources! Finally, an important thing to solve is how to perform the update check .. The NET application update component uses HTTP for communication, which allows client applications to update through the firewall. The address required for the update check becomes a URL address of a known Web server. The first problem is solved smoothly.

The. NET application update component generates a thread Based on the component generation. This thread is responsible for the update check. This thread is in sleep state most of the time, but will wake up at the set interval and implement an update check. The frequency of checks performed by applications for new updates depends on the application itself. The interval between common values for update checks generally ranges from one hour to several days. This basic round robin method is not suitable for all situations. For example, Microsoft Money is checked only when the user asks it to perform an update check. In this case, the update polling thread can be disabled.

Call the checkforupdate () method of the update component to perform the update check.

There are several methods to check for updates:

Method 1: directly check the file -- Use http to compare whether the last modification date/timestamp of the server and client application is consistent. If an updated file exists on the server, the client can update itself. The same applies to Web browsers. They know whether to download an HTML page or image or
Repeat the previously downloaded. When an application has a new version, the Administrator simply copies an updated version to overwrite the old version on the Web server. The problem with this method is that the update is not automatically performed, and a potential failure may occur. For example, if the administrator is updating the application version on the Web server and a customer is downloading the updated version, the customer's computer will have some files before the update and some new files after the update. For these reasons, direct file checks are not recommended for important applications.

Method 2: explicit check-use an explicit configuration file on the server. A valid server explicit file that can be used with the. NET application update component is roughly like this :..

<VersionConfig> <AvailableVersion> 1.0.0.0 </AvailableVersion> <ApplicationUrl> http: // localhost/demos/selfupdate/V1/</ ApplicationUrl> </VersionConfig>

Availableversion specifies the version number of the latest available assembly. The applicationurl attribute specifies the URL of the application of this version. When administrators want to update client applications, they will copy the new version of the application to the Web server and modify the server's explicit files as appropriate. The client detects that the explicit file on the server has been modified, and then downloads the explicit file. The client then compares the specified assembly version number in the explicit file with the version number of the application EXE file. If the available version number in the server explicit file is newer, the application knows that it needs to be updated. This method is recommended for most applications.

Method 3: XML Web Service check-XML WebServices provides a more advanced Update check method. For example, if you want to update a series of early users before updating your other users, if the client application calls an XML WebService to check whether an update is available, the XML Web Service can also query the user in the database and determine whether the user is an early user. If they are early users, XML Web Service returns a value indicating that the update is available. If not, the Web service returns a value indicating that the update is unavailable. However, the. NET application update component described in this article does not provide direct XML Web Service Support.

To use XML Web Service for update check, first create XML Web Service and hook an oncheckforupdate event. This allows your own custom check to replace the polling thread Update check. The oncheckforupdate event has a return value, which indicates whether the update is detected.

(2) download updates

When the. NET application update component detects a new update available, it automatically starts another thread and starts asynchronous background download updates.

Download is done with HTTP-DAV. Dav is an extended HTTP,... it provides features such as Directory and file enumeration. A complete download process starts with specifying a URL. Using URLs to download depends on the method used to complete the update check. For example, if an explicit Server File is used, the URL used for downloading the update is specified by the applicationurl attribute in the explicit Server File.

Update download obviously requires a certain degree of robustness. It is unacceptable to keep the client application in any unstable state after downloading and updating. Any problems may occur during the download process: the Web server to which the Update file belongs may be down, the client machine may crash, or, for some reason, the user simply closes the application. Because
The application is being downloaded. If it is disabled, the download will stop. An optional design scheme is to use a separate system service to download and update applications. When using the System Service, the update and download will continue even if the application is not running. In fact, Windows XP has a built-in download service called BITS, which aims at this. BITS is used by Windows XP to download and update Windows itself. For more information about BITS, see http://msdn.microsoft.com/library/en-us/dnwxp/html/winxp_bits.asp. This service is not used in the. NET application update component, so it can be used in Windows 9x that does not support system services.

(3) implement updates

The. NET application update component provides robustness by dividing the download and update processes into two separate phases. When each stage is completed, it is recorded in a manifest file located in the client application directory. If the process of downloading or updating any stage is interrupted, it will continue the original work from the last breakpoint at the next application startup. Each stage can be re-run. Therefore, if a failure occurs in the middle of a stage, re-run the stage to succeed. If an error occurs, for example, the link to the server is lost during the download process, the. NET update component will try again later. If many errors are reported (for example, the web server is no longer online), the download and update will be abandoned and an error will be reported.

Our first method is to simply start a separate process to implement updates. This separate process will first shut down the application process to implement updates (because it has been unlocked at this time), restart the application process, and close itself after completion. Therefore, this design has three basic problems:

. In some cases it does not work. When updating an application, the update process closes the original application process, and the update process itself is also disabled, so the update will not be implemented.

. We hope to automatically update all the code to be updated. We hope that the ability to automatically install and patch will not only happen to applications, but also to update the components of. NET applications. In this mode, we cannot update the update process.

It is impolite to force the user to close the application and wait during use.

The last way to update an application is to use the. NET Framework parallel Assembly mode. As an alternative to trying to update the application itself, generate an application version that is newer than the current version.

The new version can be generated by combining the existing application directory and the updated version downloaded. When the new version is complete, the new version is automatically used when you re-open the application next time. Copies of the original application can be removed. The tricky issue is to find out which version should be loaded at a specified time point. We will introduce an application named Appstart.
. Appstart is the entry point for your application. In this mode, your application directory looks like this :..

--> Program Files

--> MyApp

--> Appstart.exe

--> Appstart. config

--> V1 Folder

--> MyApp.exe

--> V1.1 Folder

--> MyApp.exe

To run your application, you usually start appstart.exe. For example, yourapp.exeappsappstart.exe is a very simple program that reads the Appstart. config file and loads the specified application. A valid Appstart. config file is as follows:

<Config> <AppFolderName> V1 Folder </AppFolderName> <AppExeName> MyApp.exe </AppExeName> <Applaunchmode> appdomain </applaunchmode> </Config>

AppFolderName specifies the subfolders that contain the application version to be run. AppExeName contains the exe file name to be loaded in that folder. When an application is updated, the last step is to change the value of AppFolderName to a new version of the application. In this way, the next time you run the application, the new version of the application will be run. AppLaunchMode specifies how to load the application. There are two ways to load the application: the first method is to use AppDomains. AppDomains is A. NET Framework Public
Features of Language Runtime are also independent logical units and management objects. When a common language is running, multiple application domains are allowed in each process. In this example, appstart.execan load your application in the same appstart.exe process. Although two different exe programs are running (appstart.exeand myapp.exe), only one process is in use. For most applications, AppDomains can work well. Of course, running in a separate AppDomain and running in a separate AppDomain
There are some minor differences in the running process. In this case, AppLaunchMode can be set to "process", which will load the application in a separate process.

Once the Appstart starts the application, it enters the sleep state and waits for the application to terminate. Once the application is terminated, Appstart is also disabled.

　　Iii. instance Drill

We have discussed how the. NET application updates work. Now we will apply the updates to the instance.

Step 1: Create an application for updates

1. Use VS. NET to generate a new Windows application project named "SampleApp ".

2. Give the form an interesting background color that you choose. We will use the background color to distinguish it from the later version.

3. Now let's add a subtle function to this application. First, add a button to your form. The compressed file contains an assembly with a simple Windows form. Add a reference to the Samples \ SampleApp \ SimpleForm assembly in the compressed file. Then, add two lines of code to the event handle:

.. Simpleform. form1 F = new simpleform. form1 (); F. Show ();

4. Convert your build flag from debug to RELEASE. This will allow us to avoid the pdb file lock issue that occurs when we generate a new version of the application while the original copy is running. Generate and test your application.

Step 2: Add a. NET application update component

1. on the component Tab Of The VS. NET toolbar, right-click and select "Custom toolbar ". Select the. NET Framework component tab. Click Browse, select AppUpdater. dll under the AppUpdater project in the compressed file, and click OK.

2. An AppUpdater icon should appear at the bottom of the component list on the toolbar. Drag and Drop the AppUpdater component to the SampleApp form. An instance of the. NET application update component named appUpdater1 appears at the bottom of the form.

Step 3: Set the. NET application to update the component

In this step, we will set the. NET application to update the component. Note that in this example, you only need to change the first four attributes and use the default values for others.

AppUpdater attribute: this is the core of. NET Application updates. You need to make the following settings for this program:

(1) AutoFileLoad: This control controls the command download feature to be described later, and now sets it to true.

(2) ChangeDetectionMode: This enumeration determines how to check for updates. In this example, an explicit Server check is used, so this value is set to "ServerManifestCheck ".

(3) showdefaui UI: the. NET application update component has a series of user interfaces to notify users of some events. For example, a new update can be used or an error occurs during the update. This kind of user interface can be replaced by setting the default user interface to be invalid and use the user interface specified by the Custom Application to hook appropriate events (such
OnUpdateComplete) and the Custom User Interface is displayed. In this example, the default user interface is used, so the value is set to true.

(4) UpdateUrl: UpdateUrl determines where the update program is located to search for updates. In this example, we use a server explicit file to check for updates. Therefore, this attribute should be set to the URL of the server explicit file.

In this example, set it to http: // yourWebserver/SampleApp_ServerSetup/UpdateVersion. xml. Please use your Web server name
To replace "yourWebserver ".

Downloader attribute: The AppUpdater component has two child components. The first is called Downloader, which controls the download of components and the attributes of Poller: the second sub-component of AppUpdater is Poller, and Poller controls the update check.

(1) AutoStart: A boolean value that controls whether Poller should start polling or whether it should wait until a Scheduled Update query starts when the application starts.

(2) DownloadOnDetection: Boolean value, which controls whether Poller starts to download updates immediately when a new update is detected, or whether to start explicit download by calling the DownloadUdpate () method.

(3) InitialPollInterval: the number of seconds that the application waits for before the first update check.

(4) PollInterval: after the first update check, PollInterval controls the number of seconds between subsequent update checks. Note: The default value is every 30 seconds.
Perform a check. Obviously, you want your application to reduce the update check frequency.

After all this is done, Your Attribute Table should look like the following:

The samples \ sampleapp \ sampleapp_complete directory contains a version correctly installed by the application.

Installation:

(1) DownloadRetryAttempts: if an error occurs during download (for example, a Web server is down), downloader will try again later. This attribute controls the number of network requests retried before downloader considers it a thorough application update error.

(2) SecondsBeteweenDownloadRety: the number of seconds to wait before retrying the network request.

(3) UpdateRetryAttempts: if a serious error occurs during the update process (for example, if downloader exceeds the number of retries), an application update error occurs. By default, update attempts will be stopped. However, the application tries to recover the service at the next startup (for example, updating the Web server may take several days to crash ). This attribute controls the number of attempts to update. If this value is exceeded, the updater will cancel the update, reset its status, and return the update check.

(4) ValidateAssemblies: This attribute controls the effective completion level of the downloaded assembly. For more information, see the Security Section in this article.

Step 4: Generate and deploy application V1 on the client.

In the SampleApp project, open the AssemblyInfo. cs file. Change the value of AssemblyVersion from 1.0 to 1.0.0.0 ". This causes the flag to get the value of "1.0.0.0" .. when the program is generated. This flag replaces VS. NET, which is usually specified as an incremental value.

1. generate an application.

2. Copy the Samples \ SampleApp \ SampleApp_ClientSetup directory from the compressed file to your local machine. You have included appstart.exe in this directory. Appstart.confighas been set to indicate to 1.0.0.0directory and start sampleapp.exe.

Sampleapp(appupdater.dll, simpleform.dll, and sampleapp.exe)

Go to the client SampleApp_ClientSetup \ 1.0.0.0 directory. To this end, the application program of a function has been installed on the client. You can run appstart.exe at the same time.

Step 5: Install the Web Server

In this step, we will install the Web server to provide the update round robin function .. NET application update components use HTTP-DAV to download application updates, so a web server that supports HTTP-DAV is required. Iis5.0 on Windows 2000 and the updated operating system both Support HTTP-Dav.

1. Copy the samples/sampleapp_serversetup directory to the wwwroot directory on your Web server.

2. Copy the V1 version of sampleapp to the 1.0.0.0 folder of the Web server.

3. Enable the "directory browsing" permission for IIS for the sampleapp_serversetup Directory on the Web server.

Step 6: automatically update the application

OK... now it's time to automatically install a new version to see the above hard work results.

1. If your customer's sampleapp.exe does not run, you can use appstart.exe instead.

2. Return to vs. NET and make some notes (such as modifying the background color) in the sampleapp form ).

3. Change the version information of assemblyinfo. CS to 2.0.0.0.

4. regenerate.

5. Return to the Web server and generate a 2.0.0.0 directory equivalent to the 1.0.0.0 directory. Copy the new version of the application to the 2.0.0.0 directory created on the web server from the release directory.

6. Open updateversion. xml and change availableversion to 2.0.0.0. Modify applicationurl to point to the new 2.0.0.0 path.

7. Save the changes to updateversion. xml.

Once you save the new updateversion. XML, the new available version will be detected in the running sampleapp copy within 30 seconds.

　Iv. On-Demand installation, security, scalability and debugging

(1) installation as needed

Installation as required means that only the main executable program is explicitly installed on the client. The remaining parts of the application can be automatically downloaded and installed as needed.

Use the. NET application to update the AutoFileLoad attribute of the component to start installation as needed. You must carefully consider the location of the Assembly boundary in your application and what actions will cause the assembly to be downloaded. Since the download of an assembly involves network input and output, the download time is variable. During the Assembly download, the application will be frozen and wait until the Assembly download is complete.

(2) deployment security

The ability to automatically install application updates has many advantages, but it is also accompanied by some potential risks. When you make the installation and update easier, you may also make the installation of malicious code easier if you are not careful. There are two dangers. The first danger is that someone will use their Web servers to cheat the Web servers used to deploy updates. They may use the Web server to install a virus program in your application path. The easiest way to prevent spoofing or other improper interventions over the network is to use HTTPS. To Use HTTPS with the. NET application update component, you can simply Use HTTPS URLs instead of HTTP URLs. Of course, HTTPS is not a silver bullet. There are two problems with using HTTPS. The first is scalability. To Use HTTPS, the server needs to encrypt all files downloaded from the Web server. If an application has a large Update file, the cost of encrypting the Update file will overload the server. Another problem with using HTTPS is that it does not benefit from the second security risk. The second risk is that hackers may attack your server either internally or externally. Once the attack succeeds, it may mean that hundreds of thousands of clients are also affected by Automatic Updates. This situation will be disastrous.

To solve this problem, the. NET application update component adds a strong name to the. NET assembly to verify the downloaded assembly. If the. NET application update component detects that an assembly is not signed using your key during download, the download will be canceled. This means that only those with the private key of your application can create update files that can be automatically deployed.

To verify that the Assembly is valid, the. NET application update component verifies that the public key of the executable program that you are currently installing matches the public key of the downloaded update. If the two sets are signed with the same and confidential private key, the embedded public key will be the same. To verify the public key of an assembly loaded by CLR, CLR calculates its normal hash value check to ensure that the Assembly is actually a real Assembly instead of an assembly. To verify the download, you can add a strong name to all your application sets and set the ValidateAssemblies attribute of the. NET application update component to true.

Assembly verification during download will play a major role, but in fact, applications often have components with different private key signatures. For example, your application may have two files: the executable assembly that uses your private key signature and the dll Assembly that contains the third-party chart controls of the application you purchased in your application. Third-party Assembly may make
Use a third party rather than your own private key for signature. To make the situation more complex, the setting of the valid Private Key used to sign the Assembly in your application may change as the version number changes. How do you automatically update the types of those applications? To solve this problem, you can generate an Assembly containing a list of valid public keys in your application. Sign the Assembly with the application's master/private key (the secret of the application's exe file signature) and place the assembly in the directory where the Web server and the application update file are located. Before the update/download process starts, the. NET application update component checks the application update Directory on the Web server for the next Assembly named "AppUpdaterKeys. dll. If yes, the Assembly will be downloaded. This Assembly is used to compare and verify the public key of the main application. If the signature is valid, the key list is extracted. From then on, any key in the list will be considered as a valid signature of the update file.

We recommend that you use HTTPS URLs for update checks. This provides the first level of Spoofing Protection. For update download, it is best not to Use HTTPS RLs to avoid overload your Web server. Instead, add a strong name to the assembly of your application and use the Assembly verification feature.

(3) scalability

In the example described earlier in this article, we simply drag and drop a component to the application and set some attributes for automatic deployment.

Although this works well in many applications, some applications require high-level control, which can only be obtained by writing code. We can write our own code to replace the standard process of. NET application updates, and use the overwritable CheckForUpdate () and ApplyUpdate () Methods to customize the check and update behaviors.

(4) debugging

This section highlights some of the preferred debugging options and describes most common problems for users who use this component.

.Netapp update generates a hidden log file named AppUpdate. log in the same directory as appstart.exe.

All successful and failed updates are recorded in this log. Log files are particularly useful when a special client fails to be updated.

You can use logs to determine when and how update failed. In addition, the. NET application update component uses the Debug class of the. NET Framework to output a large amount of useful information. If you run your application in the debugger, you will see this information in the output window. You can focus on the record of the. NET application Updater and find out
The problem.

If, for some reason, you cannot make the. NET application Updater work, determine the following points before you perform in-depth debugging. The problems you encounter may be one of the following :..

. Have you opened the IIS directory? If not, the Updater will not download and install any files.

. Have you correctly deployed everything and set the URL?

If your application is installed in the program files directory, are you sure you are the super administrator or super user of the machine? If not, you will not have the write permission to update the application.

Are you generating an AppUpdater object in the main user interface thread of the application? If not, the Updater cannot display the user interface and fails to return the event to the user interface.

. Is the update successful, but the application fails to use the new update to automatically restart ?. The NET Application update component tries to Exit the Application by calling the Application. Exit method. However, this method does not guarantee to close an application. If you generate and leave a separate thread running, this method cannot close the process. The solution to ensure the termination of all threads is to call the Application. OnExit event, or hook the OnUpdateComplete event of the. NET Application Updater and handle and close it by yourself.

　　V. Summary

Client application deployment convenience is an important goal of the first version of the. NET Framework. Using the. NET Framework to build client applications to solve deployment problems is a good technology. Ease of deployment is still an important goal of the new version of the. NET Framework in the future. For the solution, the. NET application update component described here represents some of our ideas and will be available directly in future. NET frameworks. However, during the period before that, the. NET application update component was an important way to start creating an automatic update application.