There are generally two methods of application update: one is to notify the user (such as sending an email) and ask the user to download the updated program from a designated website address; the other is to transfer the update responsibility from the user to the application itself. Instead of the user getting and installing a software update, the client application itself is responsible for downloading and installing updates from a known server. The only intervention the user needs to make is to decide whether they want to install new updates now or later. Obviously, the latter is friendlier than the former. You can now see actual products that resemble the latter approach, such as Windows XP and Microsoft Money. The .NET application update component introduced in this article can provide similar functionality.
1. Introduction to the .NET application update component
The .NET application update component AppUpdater is developed using the .NET framework. Although AppUpdater is not a Microsoft product, as long as you add the component to the VS.NET toolbar, you can drag and drop the component from the toolbar into your application just like using other components. After setting some properties (such as the location and frequency of obtaining updates, etc.), your client application can have the automatic update function.
2. Working Principle
To deeply understand the working principle of the .NET client application update component, you need to carefully study what must be done to implement client application update. The first step is to check if there is an update; when an update is found, start the second step - download the update; when the update download is completed, proceed to the last step - implement the update.
(1) Check for updates.
As a developer, you must first tell the application where to check for updates. Otherwise, wouldn’t it be like looking for a needle in a haystack? Second, determine when to check for updates. It is impossible for the user to run the client program every time and it is constantly checking for updates in the background. What a waste of resources! One last important thing to address is how to check for updates. The .NET Application Update component uses HTTP for communication, which allows client applications to perform updates through firewalls. And the address required for update check becomes a URL address of a known web server, and the first problem is successfully solved.
The .NET application update component generates a thread based on component generation, which is responsible for update checking. This thread sleeps most of the time, but wakes up at set intervals and performs an update check. The frequency with which an application checks for new updates depends on the application. Common values for the interval between update checks typically range from one hour to several days. This basic approach to polling is not suitable for every situation. For example, Microsoft Money only checks for updates when the user asks it to. In this case, the update polling thread can be disabled.
Update checking is implemented by calling the CheckForUpdate() method of the update component with a command.
There are several methods on how to perform update checks:
Method 1: Direct file check - Use HTTP to compare the last modification date/time stamp of the server and client applications to see if they are consistent. If there is an updated file on the server, the client knows it can update itself. The same is true for a web browser, which knows whether it needs to re-download an html page or image or whether it can reuse a previously downloaded one. When a new version of the application becomes available, the administrator simply copies the newer version over the older version on the Web server. The problem with this approach is that the update is not automatic, so there is a potential for failure. For example, if an administrator is updating the version of an application on a Web server, and a customer is downloading a version before the update, then the customer's computer will have some files from before the update, as well as some files from the new version after the update. document. For the above reasons, direct file checking for updates is not recommended for critical applications.
Method 2: Explicit check - use an explicit configuration file on the server. A valid server explicit file for use with .NET application update components looks something 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 address where this version of the application is located. When administrators want to update a client application, they copy the new version of the application to the Web server and modify the server explicit files appropriately. The client itself will detect that the server's explicit file has been modified, and then download the explicit file. The client then compares the assembly version number specified in the explicit file with the version number of the application EXE file. If a newer version number is available in the server's explicit file, the application knows it needs to be updated. This method is recommended for most applications.
Method three: XML Web Service check-XML WebServices provides a more advanced update check method. For example, suppose you want to update a set of early users before updating your other users. If the client application calls an XML Web Service to check whether an update is available, that XML Web Service can also query the database for that update. user and determine whether the user is an early user. If they are early users, the XML Web Service returns a value indicating that updates are available. If not, the Web Service returns a value indicating that the update is not available. However, the .NET application update component introduced in this article does not provide direct XML Web Service support.
To use XML Web Service to perform update checks, first create an XML Web Service and hook an OnCheckForUpdate event. This allows you to write your own custom checks in place of poller thread update checks. The OnCheckForUpdate event has a return value that indicates whether an update was detected.
(2) Download updates
When the .NET application update component detects that a new update is available, it will automatically start another thread and start asynchronous background download of updates.
Downloading is done using HTTP-DAV. DAV is an extended version of HTTP, which provides functionality such as directory and file enumeration. A complete download process begins by specifying a URL. The URL used to download depends on the method used to complete the update check. For example, if you use server explicit files, the URL used to download updates is specified through the ApplicationURL attribute in the server explicit file.
Update downloading obviously requires some robustness. It is unacceptable to leave a client application in any unstable state after downloading and updating. Any number of 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 the user may simply close the application for some reason. Since the application is downloading, if it is closed, the download will stop. An alternative design solution is to use separate system services for application downloads and updates. Using system services, update downloads continue even when the application itself is not running. In fact, Windows XP has a built-in download service called BITS, which serves this purpose. 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 which does not support system services.
(3) Implementing Updates
The .NET application update component gains robustness by dividing the download and update processes into two separate phases. When each stage is completed, it is recorded in an updated manifest file located in the client application directory. If the process of downloading or updating is interrupted at any stage, it will resume the original work from the last completed breakpoint the next time the application is started. Each stage can be rerun, so if a failure occurs in the middle of a stage, rerunning the stage will succeed. If an error occurs, such as the connection to the server being lost during the download, the .NET update component will try again later. If too many errors are reported (for example, the web server never comes back online), downloads and updates will be aborted and errors reported.
Our first approach is to simply start a separate process to implement the update. This separate process will first shut down the application process, implement the update (since it is now unlocked), restart the application process and then shut down itself when finished. Therefore, there are three basic problems with this design:
. In some cases it doesn't work. When an application is updated, the update process closes the original application process, and the update process itself is also closed, so the update will not be implemented.
. We want to be able to automatically update all code that needs to be updated. We want the ability to automatically install patches not just on the application, but also on the .NET Application Update component itself. Using this mode, we cannot update the process that implements the update.
. It is rude to force the user to close the application and wait while using it.
The final method used to implement application updates is to use the .NET Framework parallel assembly pattern. As an alternative to trying to update the application itself, generate a newer version of the application than the currently existing version.
New versions can be generated by merging the currently existing application catalog with downloaded updated versions. When the new version is complete, the user will automatically use the new version the next time they reopen the app. The copy of the original application can then be removed. The tricky thing is figuring out which version should be loaded at a given moment. We introduce an application named Appstart. Appstart is the entry point into your application. Using 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. If you want to have a shortcut key on the desktop, that shortcut key must point to Appstart and not directly to the application (note that you can rename AppStart.exe to anything you want, such as YourApp.exe) Appstart.exe It is a very simple program that reads the Appstart.config file and loads the specified application. A valid Appstart.config file looks like this:
<Config>
＜AppFolderName＞V1 Folder＜/AppFolderName＞
＜AppExeName＞MyApp.exe＜/AppExeName＞
＜AppLaunchMode＞appdomain＜/AppLaunchMode＞
＜/Config＞
AppFolderName specifies the subfolder that contains the version of the application currently being run. AppExeName contains the name of the exe file to be loaded in that folder. When an application update is complete, the final step is to modify the value of AppFolderName to point to the new version of the application. This way, the next time the user runs the application, the new updated version of the application will run. AppLaunchMode specifies how the application is loaded. There are two ways to load applications: The first way is to use AppDomains. AppDomains is a feature of the .NET framework common language runtime and is also an independent logical unit and management object. The common language runtime allows multiple application domains per process. This way Appstart.exe can load your application in a separate AppDomain but in the same AppStart.exe process. Despite the fact that there are two different exe programs running (i.e. Appstart.exe and MyApp.exe), only one process is being used. AppDomains will work just fine for most applications, although there are some subtle differences between running in a separate AppDomain and running in a separate process. In this case, AppLaunchMode can be set to "process", which will cause the application to load in a separate process.
Once Appstart launches the application, it goes to sleep waiting for the application to terminate. Once the application is terminated, Appstart is also closed.
3. Example walkthrough
Earlier we discussed how .NET application update works, now let's apply it to an example.
Step 1: Create an application to update
1. Use VS.NET to generate a new Windows application project, named "SampleApp".
2. Give the form an interesting background color of your choice. We will use a background color to differentiate it from later updated versions.
3. Now let's add a subtle feature 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 SamplesSampleAppSimpleForm assembly in the compressed file. Then add two lines of code to your button event handler:
..
SimpleForm.Form1 F = new SimpleForm.Form1();
F.Show();
4. Convert your build flag from debug to RELEASE. This will allow us to avoid pdb file locking issues later when we build a new version of the application while the original copy is running. Build and test your application.
Step 2: Add the .NET application update component
1. On the Components tab of the VS.NET toolbar, right-click and select "Customize Toolbar". Select the ".NET Framework Components" tab. Click "Browse" and select AppUpdater.dll located under the AppUpdater project in the compressed file, click OK.
2. An AppUpdater icon should now appear at the bottom of the toolbar's component list. Drag and drop the AppUpdater component onto the SampleApp form. An instance of the .NET Application Update component named appUpdater1 appears at the bottom of the form.
Step 3: Set up the .NET application update component
In this step we will set up the .NET application update component. Note that in this example you only need to change the first four properties, leaving the rest at their default values.
AppUpdater attribute: This is the core of .NET Application application update. The following settings need to be made for this program:
(1) AutoFileLoad: This controls the command download characteristics to be described later. Now set it to true.
(2) ChangeDetectionMode: This enumeration determines how to check for updates. In this example, we will use a server explicit check, so set this value to "ServerManifestCheck".
(3) ShowDefaultUI: The .NET application update component has a series of user interfaces to notify users of some events, such as a new update being available or an error occurring during the update. This UI can be disabled by setting the default UI to invalid and replacing it with a custom application-specific UI, hooking into the appropriate events (e.g.
OnUpdateComplete) and pop up the custom user interface. For this example we will use the default user interface, so set this value to true.
(4) UpdateUrl: UpdateUrl determines where the update program will look for updates. In this example we are using a server explicit file to check for updates, so this property should be set to the URL of the server explicit file.
In this example set it to: http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xml . Please replace "yourWebserver" with your Web server name.
Downloader Property: The AppUpdater component has two subcomponents. The first is called Downloader, which controls the download and Poller properties of the component: The second subcomponent of AppUpdater is Poller, which controls update checking.
(1)AutoStart: Boolean value that controls whether the Poller should start polling when the application starts or whether it should wait until a planned update query starts.
(2) DownloadOnDetection: Boolean value, controls whether Poller starts downloading updates immediately when a new update is discovered, or whether to start explicit downloading by calling the DownloadUdpate() method.
(3)InitialPollInterval: The number of seconds to wait before performing the first update check after the application is started.
(4)PollInterval: After the first update check, PollInterval controls the number of seconds between each subsequent update check. Note: The default is to check every 30 seconds; obviously, you will want your application to reduce the number of update checks. frequency.
After all this is done, your properties table should look like this:
The SamplesSampleAppSampleApp_Complete directory contains a correctly installed version of the application.
Installation:
(1)DownloadRetryAttempts: If an error occurs during downloading (such as the Web server is down) the downloader will try again later. This property controls the number of times the downloader retries a network request before deeming it a complete 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 (for example, the downloader exceeds the number of retries), an application update error will be generated. By default, attempts to update will be stopped. But it will try to recover the next time the application starts (for example, updating the web server may be down for several days). This property controls the number of times an update is attempted. If this value is exceeded, the updater cancels the update, resets its state and returns to update checking.
(4)ValidateAssemblies: This attribute controls the level at which downloaded assemblies are effectively completed. See the Security section of this article for more information.
Step 4: Generate and deploy application V1 version on the client.
In the SampleApp project, open the AssemblyInfo.cs file. Modify the value of AssemblyVersion from "1.0" to "1.0.0.0". This causes when building the assembly to get a tag with the value "1.0.0.0".. instead of the value that VS.NET normally specifies as an increment.
1. Build the application.
2. Copy the SamplesSampleAppSampleApp_ClientSetup directory from the compressed file to your local machine. Note that this directory already contains AppStart.exe. AppStart.config has been set to point to the 1.0.0.0 directory and start SampleApp.exe.
Copy SampleApp (Appupdater.dll, SimpleForm.dll and SampleApp.exe) from the release directory of SampleApp
to the client SampleApp_ClientSetup1.0.0.0 directory. At this point, a fully functional version of the application has been "installed" on the client and can be executed by running AppStart.exe.
Step 5: Install the Web Server
In this step we will install the Web server to provide update polling functionality. The .NET Application Update component uses HTTP-DAV to download application updates and therefore requires a web server that supports HTTP-DAV. IIS5.0 on Windows 2000 and newer operating systems 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 Browse" permission of IIS for the SampleApp_ServerSetup directory on the web server.
Step Six: Automatically Update Applications
OK,... Now it's time to see the results of all this hard work by automatically installing a new version.
1. If the version of SampleApp you deployed on the client is not running, load it and let it run. Remember to use AppStart.exe.
2. Go back to VS.NET and make some noticeable changes in the SampleApp form (such as changing the background color).
3. Change the version information of AssemblyInfo.cs to 2.0.0.0.
4. Regenerate.
5. Return to the Web server and generate a directory 2.0.0.0 that is equivalent to the 1.0.0.0 directory. Copy the new version of the application from the release generation directory to the newly created 2.0.0.0 directory on the Web server.
6. Open UpdateVersion.xml and modify AvailableVersion to 2.0.0.0. Modify the ApplicationURL to point to the new 2.0.0.0 path.
7. Save the changes made to UpdateVersion.xml.
Once you save the new UpdateVersion.xml, within 30 seconds, running copies of SampleApp will detect the new available version.
4. On-demand installation, security, scalability and debugging
(1) On-demand installation
The so-called on-demand installation means that only the main executable program is explicitly installed on the client computer. The rest of the application can be automatically downloaded and installed based on basic needs.
Initiate on-demand installation through the AutoFileLoad property of the .NET application update component. You must carefully consider where assembly boundaries lie within your application and what actions will cause the assembly to be downloaded. Because the download of the assembly involves network input and output, the time it takes to download is variable. During the assembly download, the application is frozen waiting for the assembly download to complete.
(2) Deployment
The ability to automatically install application updates securely has many benefits, but it also comes with some potential dangers. When you make it easy to install updates, you can also make it easy to install malicious code if you're not careful. There are two dangers. The first danger is that someone will use their own web server to trick the web server used to deploy updates. They may use that web server to install a virus in your application path. The simplest way to prevent spoofing or other improper interference over the network is to use HTTPS. To use HTTPS with the .NET Application Update component, simply replace HTTP URLs with HTTPS URLs. Of course, HTTPS is not a silver bullet. There are two problems with using HTTPS. The first is scalability. Using HTTPS requires the server to encrypt all files downloaded from the web server. If an application's update files are large, the cost of encrypting the update files can overburden the server. Another problem with using HTTPS is that it does nothing to benefit the second security danger. The second danger is that hackers can attack your server from the inside as well as from the outside. If the attack is successful, it may mean that hundreds or thousands of clients are also affected by automatic updates, which would be catastrophic.
To resolve this issue, the .NET Application Update component uses the strong name feature for .NET assemblies to verify downloaded assemblies. If the .NET Application Update component detects that an assembly is not signed with your key during download, the download will be canceled. This means that only someone with your application's private key can create updates that can be deployed automatically.
To verify that the assembly is valid, the .NET Application Update component verifies that the public key of your currently installed application executable and the public key of the downloaded update match. If two assemblies are signed with the same secret private key, then the embedded public key will be the same. Because the assembly being loaded by the CLR verifies its public key, the CLR computes its normal hash check to ensure that the assembly is in fact a genuine assembly and not a tampered assembly. To enable validation at download time, add strong names to all your application assemblies and set the ValidateAssemblies property of the .NET Application Update component to true.
Assembly verification at download time helps a lot, but in practice, applications will often have components signed with different private keys. For example, your application might have two files: an executable assembly signed with your private key and another dll assembly that contains a third-party chart control that you purchased and used in your application. Third-party assemblies may be signed using the third party's private key instead of your own. To further complicate the situation, the setting of valid private keys used to sign assemblies in your application may change from version number to version number. How do you automatically update those application types? To solve this problem, you can generate an assembly in your application that contains a list of valid public keys. Sign the assembly with the application's master private key (the key used to sign the application's exe file) and place the assembly in a directory on the web server with the application update files. Before the update download process begins, the .NET Application Update component will check for an assembly named "AppUpdaterKeys.dll" in the application update directory on the Web server. If present, the assembly is downloaded. The assembly is verified against the main application's public key. If the signature is valid, the key list is extracted. From now on, any key in this list will be considered a valid signature for the updated file.
The recommended security approach is to use HTTPS URLs for update checks. This provides the first level of spoofing protection. For update downloads, it is best not to use HTTPS RLs to avoid overloading your web server. Instead, add strong names to your application's assemblies and use the assembly validation feature.
(3) Scalability
In the example mentioned earlier in this article, we simply dragged and dropped a component into the application and set some properties to achieve automatic deployment.
While this works well in many applications, some applications require a high level of control that can only be obtained by writing code. We can write our own code to replace the .NET application update component standard process, using overridden CheckForUpdate() and ApplyUpdate() methods to customize the check and update behavior.
(4) Debugging
This section will point out some preferred debugging options, as well as describe the most common problems faced by users of this component.
The .NET Application Updater generates a hidden log file named AppUpdate.log in the same directory as AppStart.exe.
All update success and failure information are recorded in this log. The log file is particularly useful when a particular client fails to update successfully.
You can use the logs to determine when and how updates failed. Additionally, the .NET Application Update component uses the .NET Framework's Debug class to output a wealth of useful information. If you run your application in the debugger, you will see this information in the output window. You can follow the .NET Application Updater's logs to highlight and find the problem areas.
If for some reason you are unable to get the .NET Application Updater to work, please make sure of the following before you delve into debugging. The problem you are encountering is most likely one of the following: ..
Did you browse to the IIS directory? Opened? If not, the updater will not download and install any files.
. Did you deploy everything correctly and set the URL correctly?
. 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 won't have write access to update the application.
. Are you generating the AppUpdater object in the application's main UI thread? If not, the updater will not be able to display the UI and will fail when firing an event back to the UI.
. Does the update succeed but the application fails to automatically restart with the new update? The .NET Application Update component attempts to exit the application by calling the Application.Exit method. However, this method does not guarantee closing an application. If you spawn and leave a separate thread running, this method cannot shut down the process. The solution to guarantee that all threads terminate is by calling the Application.OnExit event, or hooking into the .NET application updater's OnUpdateComplete event and handling the shutdown yourself.
5. Summary
Convenient deployment of client applications is an important goal of the first version of the .NET framework. Using the .NET framework is a great technique for building client applications that solve deployment problems. Ease of deployment remains an important goal for future new versions of the .NET Framework. As a solution, the .NET application update component described here represents some of our ideas that we will be able to use directly in future versions of the .NET Framework. However, in the period before that time comes, the .NET application update component can be regarded as an important way to start building automatic update applications.
From: csdn, I saw it on Tianji, I haven’t studied it carefully yet, I’ll leave it for later. refer to