Use. Net and the smart transmission API in the background to write automatic update applications.

Use the. NET and smart transmission API in the background to compile automatic update applications. Release Date: 11/26/2004 | update date: 11/26/2004

Jason clark

This document assumes that you are familiar with C # and Visual Basic. net.

Download the code in this article: bits.exe (363kb)

Summary

Both. NET Framework and windows have interesting APIs that can be used to create applications that automatically update themselves over the network. Writing apps that can update themselves like Windows Update has many benefits, including convenience for users, as it makes maintenance and network management easier. Automatic Updates require detection, security, file replacement, and other factors. In this article, the author introduces the bits API and many of the. NET Framework's functions for Processing Automatic Updates (using the same features as Windows Update.

Content on this page

	Difficult
	Basic bits knowledge
	BITs, COM, and managed code
	Combine bits with automatically updated applications
	Considerations about bits
	. NET Framework and security
	Strong name and Security binding
	Update packaging and replacement
	File replacement and Extraction
	Autoupdateapp.exe Sample Application
	Automatically update the application

I must admit that I like Windows Update. During the boot time of my computer, about 85% of the time was connected to the Internet. However, like many people, of course I would not have used the network for so much time. Windows XP uses this unused bandwidth to compare the latest online service packages and patches available with the installed service packages and patches on my computer. If it finds the updates I need, it downloads them in the background. After the installation is complete, Windows notifies me that a new software package needs to be installed on my computer.

If you can, I want to allow automatic updates for every application on the client like windows. There are many favorable conditions and ready-made connections to implement this function. To enable the application to automatically update itself, you must write code to handle issues such as discovery, download, security, and replacement.

To handle actual downloads, I will introduce a new feature of Windows: Background Intelligent Transmission Service (BITs ). After discussing this feature, I will introduce the features that can be used to automatically update application security and replace problems in. NET Framework.

Note that although bits 1.5 can be rereleased to work well on Windows 2000 and Windows XP, Microsoft does not intend to support bits APIs on Windows 9x or Windows ME. BITs is expected to be provided as a component for future Windows versions.

However, before starting the following content, it is important to note that to enable your application to use the technology described in this article, you need to manage it under. net. Bits itself is part of the operating system, and the. NET Framework technology introduced here can be used for automatic update of unmanaged applications.

Difficult

To find updates on the remote server, your application requires a method to query the network. This requires network code and simple protocols that allow applications and servers to communicate with each other. I will continue to discuss the topic "discovery" later in this article.

You must be able to download the software package. As. NET is easy to use on the Internet, downloading may not seem like a big problem, but downloading files requested by users is only one aspect. Another aspect is to download large files without the user's consent. Courtesy automatic update applications only use the residual bandwidth to download updates. This sounds good, but you will see that it brings a very difficult technical problem. Fortunately, the corresponding solution already exists.

Security may be the first problem. Take a moment to think about the Windows Update function. One of its main goals is to obtain security patches. Think about it. What if Windows Update itself cannot confirm whether it is installed with secure code? Obviously, security is a top priority for any application that downloads code from the Internet and executes the code. Therefore, I will explore how to ensure the security of automatically updated applications.

The last factor to consider is the process of replacing the application with the new version of the application itself. This issue is notable because it requires code to run when it deletes itself from the system. There are many ways to deal with this technique.

One of the most fortunate things about these difficulties is that between. NET Framework and windows, all tools are ready-made and can be immediately used to solve these problems.

Back to Top

Basic bits knowledge

Bits is a very practical file transfer feature added in windows. It downloads files from remote servers asynchronously over HTTP. BITs can use idle bandwidth to process multiple download tasks of multiple users. Although bits is not only used to automatically update applications, it is a basic API used for Windows Update. In addition, because it can be used for any application, it can be used to complete most of the very difficult work involved in the process of creating an automatic update application.

The following is the basic idea. The application requests bits to process the download of one or more files. Bits adds the task to its own queue and associates the task with the user context where the application runs. As long as the user logs on, BITs Uses idle bandwidth to search for these files in the network. In fact, the name of BITs technology is drizzle, which proves to be a very appropriate description of the work performed by bits.

So how does it work? This technology is actually a very complex technology. First, BITs is implemented as a Windows Service. It maintains a set of tasks organized into a group of priority queues. Priorities include foreground, high, normal, and low. It allocates bandwidth to each task of the same priority through a time slice of about five minutes according to the cycle method. Once there are no remaining tasks in the queue, check the tasks in the next priority queue immediately.

Tasks in the front-end queue use as much network bandwidth as possible. For this reason, the front-end priority should be used only for codes that respond to user requests. The remaining priorities (high, normal, and low) are far more interesting than the foreground priorities, because they are all background priorities, that is, they only use unused network bandwidth.

To implement this background function, BITs monitors network data packets and ignores data packets that do not belong to it. The remaining data packets are considered as active loads on the computer bandwidth. Bits uses the active load information, connection speed, and other statistical information to determine whether to continue downloading files or pause (to increase the throughput of active users ). Therefore, the user will not encounter bandwidth problems.

It is very important for bits to be able to immediately interrupt its work. In many cases, BITs has to give up or even completely disconnect from the network when only part of the file is downloaded. However, some downloaded files will be saved, so that when bits captures the opportunity to connect to the network for a moment, it will be able to continue downloading from the interrupted location. This recovery function also has some side effects.

Remember that BITs is used to transfer files from the HTTP server. To enable bits to work, the server should be compatible with HTTP 1.1, or at least support the range header in the get method. This is because bits needs to be able to request part of the file. In addition, the downloaded content must be static content, such as marking a file, code file, bitmap, or sound. When the request is dynamic (for example, CGI, ISAPI, or content generated by ASP. NET), the GET request containing the range header is meaningless.

Currently, BITs has two versions: 1.0 and 1.5. Bits 1.0 is provided along with Windows XP and has the following features: optional notifications that can be used with the dialog box and other UI elements, including resumable Background File Download, download priority, task completion, error, and progress notifications. Bits 1.5 is provided along with windows. NET Server. In addition to the features included in BITs 1.0, version 1.5 also provides resumable background file uploads and the use of "Basic", "summary", "NTLM", "negotiation" (Kerberos) or "Passport" to authenticate the connection. Bits 1.5 is also provided as a re-release software compatible with Windows 2000 and later (see smart transmission in the background ).

All the features in BITs 1.0 are sufficient for writing automatic update applications, but the bits 1.5 feature can be used to execute more complex tasks, such as selling updates or processing interactions between applications and servers.

Back to Top

BITs, COM, and managed code

Bits APIs are implemented as COM objects. Therefore, you cannot compile APIs of the. NET Framework version. Fortunately, BITs APIs are very easy to use. The example application in this article is written in C #. Therefore, to use the bits API, I have to use the com InterOP function of. NET Framework. I will not go into the Runtime Library callable packaging (RCW) and related content here, but will simply explain the process I followed when using this API.

If I use C ++, the initial part of my bits code may be as follows:

IBackgroundCopyManager* pBCM = NULL;
hr = CoCreateInstance(__uuidof(BackgroundCopyManager), NULL,
CLSCTX_LOCAL_SERVER, __uuidof(IBackgroundCopyManager), (void**) &pBCM);
if (SUCCEEDED(hr))
{
// Party-on with the pBCM interface pointer
} 

The equivalent C # code uses the New Keyword to create a backgroundcopymanager object, and then gets a reference to the ibackgroundcopymanager interface through conversion, instead of calling methods like cocreateinstance or QueryInterface. The following code snippet is a C # example. Its function is to obtain the ibackgroundcopymanager interface:

IBackgroundCopyManager bcm = null;
// Create BITS object
bcm = (IBackgroundCopyManager)new BackgroundCopyManager();

The simplicity of this Code is a little misleading because more work is required to associate the managed backgroundcopymanager and ibackgroundcopymanager types with the underlying COM Object and interface. . NET Framework processes interaction with COM objects through RCW. To associate a hosted type with RCW, you must use properties. The code in Figure 1 illustrates how to declare the backgroundcopymanager class and the ibackgroundcopymanager interface so that they represent bits COM objects.

The code in Figure 1 has many attributes (comimportattribute, guidattribute, marshalasattribute, and so on), which makes the real code look invisible. In fact, there is no real code. The definition of interfaces and classes is actually just a placeholder for sending messages in the form of metadata. The Common Language Runtime Library (CLR) uses it to directly call the bits com api.

The interopbits. CS file contained in the sample code (see the link at the top of this article) provides C # InterOP code for all interfaces, enumeration types, and structures used with bits APIs. Although the example uses only a few methods, I provide a complete implementation because it helps you explore more functions of this API. It is worth noting that the code in the interopbits. CS file is not a hosting API, but an InterOP API on the com api implementation. One day, Microsoft will publish APIs that expose the bits function to. NET Framework code using the same method as the rest of the. NET Framework class library.

The code in Figure 1 and the complete implementation in the interopbits. CS sample file are created manually. The. NET Framework SDK comes with a tool named tlbimp.exe. If you have a TLB file describing the target com api, you can use this tool to create similar code and compile it into a hosted assembly. The bits API does not contain the TLB file. However, the Platform SDK contains an interface definition file named bits. IDL, which contains the interface description.

I used the midl.exe tool (also provided with the Platform SDK) to create a TLB File Based on bits. IDL. Then, a managed Assembly representing the TLB file is created using tlbimp.exe. I use ildasm.exe to decompile the Assembly generated by tlbimp.exe into an intermediate language. Finally, I used the intermediate language as the criterion to generate the C # code, and adjusted the Code to make it easier to use and more correct. This method of combining com InterOP with C # is undoubtedly boring, but it can fully control the final result.

Back to Top

Combine bits with automatically updated applications

The BITS Service manages file downloads as tasks. The application creates a transfer task and adds one or more files to the task. Once the file list of the task is created, the task continues because the initial status of the task is suspended. Tasks are used to manage details such as priority, authentication, and error management. Applications can cancel tasks at any time.

Once the bits completes the transfer of all files in the task, the application will call a method to complete the task. The complete method copies all files to their final destination. Although the bits document calls task completion a "copy" file, a temporary hidden file is actually created in the target directory. The complete method only renames the hidden file and enables it to be viewed.

Even if you only use the minimum bits API (only the ibackgroundcopymanager and ibackgroundcopyjob interfaces are used), you can automatically update everything required by the application. More interfaces are required if task enumeration or completion or error notification are required.

The example application autoupdater.exe uses bits to discover and download updates. For this reason, the application defines the mode for consecutive name update: for this example, I chose update1.dll and update2.dll, and so on. Although this is by no means the only method for discovering updates, It is very suitable for the bits function. To store the Update Status, the sample application maintains an XML file. The two sections in this file are the guid of the next update number and description of the current BITs download task (if there is an ongoing task.

Each time the application runs, open the XML file to check whether the next update has been downloaded. If no task guid exists in the XML file, the application starts a bits task to download the next update in the sequence. The following code shows how to start a download task:

Ibackgroundcopyjob job = NULL;
// Create a bits job to download the next expected update
BCM. createjob ("application update ",
Bg_job_type.bg_job_type_download, out jobid, out job );

// Add the file to the job
Job. AddFile (updateurl, locallocation );
Job. Resume (); // start the job in action

The call to job. AddFile transfers the location of the downloaded file and the complete local path and file name of the final file to be stored when the task is completed. Note that the task is started in the suspended state. Therefore, the task must continue before the BITS Service uses the task to execute any work.

If the XML file contains a guid, the bits task is started with the last startup of the automatically updated application. Therefore, this GUID is passed to the ibackgroundcopymanager. getjob method to check whether the previous download task has produced results. The next step depends on the task status.

As shown in figure 2, if the task is in an error state, the application completes the task (clearing failed tasks from the queue ), then, create a new task for the same Update file. Generally, the cause of this error is that the name update does not exist. So far, the Discovery part of the sample application has been completed.

The biggest advantage of using bits to poll updates is that BITs works in the background. Therefore, although polling is not so satisfactory, the unforced features downloaded by BITs make it very suitable for discovering updates.

If the task is in the transferred status, the application will call ibackgroundcopyjob. Complete to complete the task. This causes the file to be placed in the target directory so that it can be updated at any time. Then the application returns. At this point, the download part of this problem is solved.

Finally, by default in Figure 2, the sample application only returns a task and does not process it. This task may be in either of the following statuses: Transmission status (meaning the task is in progress) or temporary error status. Both cases are considered to be successful, so the application does not process it. If the bits task is placed in a temporary error state, The BITS Service considers that the error may be recovered and will try again. Finally, a task in the temporary error state is either successful or put in the error state by bits.

Surprisingly, in addition to the error recovery logic, this also involves the entire discovery and download section of the autoupdater.exe sample application. As for the advanced features of the download process, its implementation seems to have almost no similarities with network communication, but has more in common with file replication. However, in production applications, you may find various applications with other features of BITs APIs, such as automatic transmission notifications, task priority processing, and upload tasks.

Back to Top

Considerations about bits

The design bits is never intended to start a network connection. This is the best consideration, because you do not want apps that are not connected to the Internet to call the ISP just to round-robin updates. However, BITs 1.0 and 1.5 both have limitations in terms of shared Internet connections. If system A shares the Internet Connection of system B, system B may start dialing when the application starts the bits task on system. This is because the current implementation of BITs does not take connection sharing into account.

This is a very tricky issue. Maybe bits will provide corresponding solutions in future versions. Windows Update features also face the same problems. In terms of this (enable dialing on a shared connection), BITs applications are no different from Windows applications.

The last concern about bits is the consistency of task files. If a download task contains multiple files, before all files are available, BITs does not think that the task has been completed or that the file has reached its final destination. However, BITs cannot know whether a file on the server has changed after being downloaded from another file in the task. Therefore, updates made on the server will affect the download consistency on the client.

There are two ways to deal with this problem. The first is to split the bits download into multiple single file tasks, which is the method I used in the sample application. The second method is to store all files of each task in a separate directory on the server. When updating files, a new directory is created for the new files on the server. In this way, the client in the intermediate transmission status of a previous task will not be affected by this new set of files. The problem caused by this solution is that when the file location on the server side changes, the client needs a way to know where to find the new file.

If you find that you need to solve the problems in BITs code, there is no more suitable tool than bitsadmin.exe. This tool is provided in the support/tools subdirectory of Windows xp cd. To avoid installing the tool to save time, I manually extract. EXE from the support. cab file.

As you get familiar with bits downloading, you will find that the bitsadmin.exe tool is very useful. You can use the switch in this command line tool to access almost every function of the API. You can also enumerate tasks, check task statuses, and view detailed logs and error messages. Allows you to start, pause, continue, and complete download tasks. Finally, you can change the task priority and cancel the task from bitsadmin.exe.

Few accompanying tools can easily access windows APIs. In fact, scripts like batch files can use bitsadmin.exe to fully use bits. BITs is an amazing solution that can be used to discover and download updates. For most applications, its shortcomings are insignificant. Now let's take a look at security.

Back to Top

. NET Framework and security

To be used in code,. NET Framework introduces some very interesting security structures. For example, code access security is a structure like this. Another security infrastructure is strongly bound to the name of the hosted assembly. To securely transmit code from the server to the client, I chose to use this function. The problem here is that the application is automatically updated to contact the server over the Internet and download files (including the code that will be installed on the client ). These new files must be protected to prevent them from being manipulated by a malicious party between the client and the server.

One solution to this problem is to perform the entire data exchange through the HTTPS connection. The BITS Service can search for resources through the HTTPS protocol. HTTPS only occurs in the encrypted SSL/TLS channel. However, this solution has several defects. First, it causes performance degradation.

The Web server performs well in sending static content (such as HTML or EXE files. When Microsoft Internet Information Service (IIS) receives a request for a static file, it can send a request to transmitfile Win32? API sends a call. At the driver level, transmitfile sends files from the file system to the network stream one by one, providing excellent performance. The introduction of Encryption Through HTTPS also greatly reduces the performance, because each byte of the file must be encrypted. This increases the cost associated with the Update Server.

Another problem with HTTPS is that it makes the Web server a very vulnerable node in the security infrastructure. If the Web server is cracked, the client will blindly download and install malicious content installed on the server.

However, the use of. NET Framework is a very simple function, you can achieve more secure Update file transmission while avoiding all these shortcomings. First, an encrypted SSL/TLS channel is required (so that the Web server throughput is not affected ). Next, because a major security threat from the compromised server is a denial of service (DoS) to the client, this solution will prevent the server from running malicious code on the client. This function of. NET Framework is called strong name binding and is part of the assembly loader.

Back to Top

Strong name and Security binding

A long-term DLL problem solved by. NET Framework is the weak name scheme, that is, only the file name is used to identify reusable code. This problem has caused all types of application problems to be called "DLL hell ". The solution is strongly named.

A strong name contains four parts: file name, version number, region information, and public key. . NET Framework uses strong names to enforce stricter binding between components. This framework also uses a public key/key pair to verify a strong-name Assembly before it is loaded. For a strongly-named assembly, the. NET Framework language compiler (C # Or Visual Basic. Net) directly generates the public key as a DLL file. In addition to the public key, the compiler also performs hash calculation on the file content and uses the private key (secure by the generated organization) to encrypt the results.

The encrypted hash is also called a digital signature. To check the digital signature, you need to extract the public key from the Assembly file and use it to decrypt the hash. Then, re-hash the file content and compare the result with the signature hash. If the Assembly content changes, signature verification fails because the hash value does not match.

You may guess that using the public key in the Assembly to confirm that the identical assembly is not safe, indeed. However, if there is a way to confirm that the public key is a well-known or expected public key, you have a more complete security solution. . NET Framework implements this function by using the hash of the public key (known as the Public Key tag or the initial public key.

When you load an assembly to an application, you can specify the Public Key tag. The. NET Framework loads the Assembly only when the Assembly has a public key with a strong name that matches the Public Key tag passed to the Assembly. Load Method.

Next, I will gradually demonstrate the process of using a strongly named assembly and using the initial public key to load it. The following C # code can be used to generate a strongly-named assembly. This Assembly cannot perform any other functions except strong name binding:

using System.Reflection;[assembly:AssemblyKeyFile(@"Keys.snk")]

To generate this code, you must first create a key file (Keys. SNK) that contains the public/private key pair ). You can use the sn.exe tool that comes with the. NET Framework SDK to perform this operation from the command line. The command is as follows:

>sn -k Keys.snk

Now, you can use the C # compiler to compile a strongly-named assembly into A. NET Framework Assembly DLL. The command is as follows:

>csc -t:library StrongName.cs

The generated assembly is named strongname. dll. To find the Public Key tag generated by this strong name, you can use sn.exe with/T switch, as shown in 3.

Figure 3 extract the Public Key tag of an assembly

The example in Figure 3 shows the DLL marked with the public key as d586e46fd39d13b5 (hexadecimal. To use strong name verification to load this assembly, you only need the following code:

// Load the update
String name = path. getfilenamewithoutextension (patchname );
Name = "strongname. dll, publickeytoken = d586e46fd39d13b5 ");
Assembly update = assembly. Load (name );

This code verifies the signature. If it succeeds, a reference to the Assembly object is returned. If it fails, the Assembly. load method will cause fileloadexception. In either case, with assembly. load, this code can verify that the Assembly has not changed since it was generated.

Automatic update applications can use bits to download update files without the need to consider server-side security. Then, you can use assembly. Load to verify the Assembly before installing and using updates on the client. The only prerequisite is that the initial application is installed using an existing public key/key pair (from the perspective of public key marking. Any subsequent updates generated using matching key pairs can be verified on the client before they can be installed and used. In the meantime, the key pair files used to generate updates can be stored on any computer, or even on a computer that is not connected to the network.

This security mechanism is amazing, but it also brings about two problems. For example, can I update non-code files like bitmaps and data files? Do you need to generate all DLL and exe files with a strong name to use this mechanism? The answers to these two questions are "yes" and "no ".

Back to Top

Update packaging and replacement

If the automatic update solution cannot be used for non-code files, or if it requires that all DLL and exe files are hosted and have a strong name, it will be less attractive to me. Therefore, I need to find a method that can be bound with a strong. NET Framework name when not only the. NET Framework Assembly file is updated. The answer is to embed the Update file into the Assembly file like the Assembly resource. This not only enables strong name protection for any file type, but also allows all update tasks to be downloaded in the form of a single file, thus simplifying the bits task creation process. A large file is actually a package containing many files. In fact, a package may contain a cab file or even an MSI script-there is no such possibility.

All. NET Framework compilers allow embedding arbitrary files into assembly files. I will show you how to use the C # compiler to do this, but its principle also applies to Visual Basic. Net or hosted C ++. The following command line will generate files such as code.dllw.bitmap.gif and data. xml into update2.dll (the preceding three files are each included in update2.dll as an embedded Resource ):

csc /res:Code.dll /res:Bitmap.gif /res:Data.xml /out:Update2.dll     /t:library

Note that the C # compiler is flexible, and DLL assembly can be generated without the. CS code file. This dll only contains embedded resources. However, if you want the DLL to contain a strong name, you should also include a brief. CS file (including code similar to strongname. CS ).

Find the embedded resource and copy it back to the file system. The code is shown in Figure 4. This Code uses the Assembly. getmanifestresourcename and assembly. getmanifestresourcestream methods to locate the resource and copy the bytes to the file system. The code in Figure 4 does not retain the date of the original file in the file system. However, to do so, you can easily modify the code. Note that the extraction process only occurs after assembly. Load verifies the signature of the container assembly.

Back to Top

File replacement and Extraction

Extracting files into the application directory during application updates is a very important issue, even if the file has a strong name and Assembly resources. The crux of the problem is that the application Copies files to its own files during execution. What's more complicated is that the running application may be an application like notepad. It is common for such applications to run multiple instances at the same time.

If your application is of this type, it is almost impossible to implement a full-range solution. Instead of specifying a single solution, let's take a look at the functions that can be used to handle replacement problems. First, it is obvious that the automatic update function can be run in a separate process different from the main application. This method is especially useful if your application is not hosted and you want to scale it so that you can use the technology described in this article. The update process can process all bits logic and file extraction. The update process can even wait until all instances of the main application are terminated, and then try to extract files.

There are three main disadvantages of running extract code in a separate process: first, it may make it difficult to fix and automatically update the Code itself. Second, this method is not advantageous on the server, because the server is unlikely to be shut down. Third, if the main process is managed by a Windows job object (do not confuse it with bits tasks), the automatic update process is automatically terminated by windows when the main process exits.

The autoupdateapp.exe sample application runs the automatic update logic in the process where the main application logic is located. If you select this option, you will encounter problems because the DLL and exe files being used by the process will be deleted and replaced. A rare technique for deleting a DLL or EXE is to rename the file to a temporary file name and then copy the new file to the old file name. Then, you can use the movefileex Win32 API to record the files to be deleted when the system restarts, or include the logic in the application that will search for and delete each temporary file.

Even with the rename technique, you still have to consider the possibility that when the update is in progress, the user runs another instance of the application, so that it will load half of the old file. There are two ways to solve this problem. One is to use the image copy function of the application domain in CLR.

CLR runs managed code in a logical application container named application domain or appdomain. Multiple AppDomains can run in a Windows process. After the appdomain is created, you can mark the new domain as an image copy object. This means that when your application loads the Assembly, the Assembly file is copied to the hidden temporary directory and loaded from the image location. The ASP. NET class in the. NET Framework uses this function to avoid application files, so that they can be updated by the ASP. NET code generator.

AppDomains can also be used for application re-execution. Ideally, when an update is available, the application prompts the user to determine whether to apply the update. If the user's answer is "yes", the application will only use the new function to run in the appropriate place. For some applications, it is acceptable to restart updated applications in the new process. In other cases, it is recommended that the new Code start working immediately in the process where the updated EXE is executed.

Using appdomain can easily re-execute the managed exe. The code example for executing this function can be found in the relaunchexe method of the sample code contained in this article (see the link at the top of this Article. The relaunchexe method creates an appdomain, re-executes the executable file, and passes the same command line parameters used to start the application at the first position to the file.

Back to Top

Autoupdateapp.exe Sample Application

The sample code in this article not only contains the automatic update logic, but also generates two updated versions of the application so that you can dynamically see the entire solution. Now let's take a look at this example.

Even though Visual Studio? . Net is a powerful encoding environment, but sometimes you have to create your own batch generation. My project is difficult to use as an example of multi-version generation generated by Visual Studio projects. Therefore, I publish the example as a collection of source files and batch files so that it can be generated from the command line.

To try this application, download the archive file from the link at the top of this article and decompress it to an empty directory. Then run build. bat from the command line. To ensure that the batch file is successful, csc.exe (C # command line compiler) and sn.exe (strong name utility) must both be in the PATH environment variable. Csc.exe is located in the directory c:/Windows/Microsoft. NET/framework/In the. NET Framework installation area /. The sn.exe tool is located in.. NET Framework SDK Directory, which is usually installed in one of the following two locations: C:/program files/Microsoft. net or C:/program files/Microsoft Visual Studio.. net.

After a project is generated using build. bat, two important directories are created: app and updates. Note that an SLN file will appear so that you can easily use Visual Studio. NET to edit the code file (however, you should continue to use the batch file to generate the project ).

The first directory contains the app for installation. Change this directory to the application directory, and then run autoupdateapp.exe to try it out. The actual function of this application is to display the first bitmap it finds in the startup directory (see figure 5 ).

Figure 5 automatically update a simple application

To dynamically view updates, create an IIS virtual root directory named updates (grant anonymous download permission ). Http: // localhost/updates is used to publish all updates. Copy the content of the second updates directory to the virtual root directory.

If everything is properly configured, your application should now be able to find update1.dll and update2.dll at http: // localhost/updates. Execute and disable autoupdateapp.exe several times from the command line. The application should notify you about the first update of the application when it is started for the second or third time. The first update only adds the new GIF file to the directory. The second update truly installs a new copy of autoupdateapp.exe, which now has a function to run the slide show of all GIF files in the startup directory.

When autoupdateapp.exe is started for the first time, the application creates a data file named updatestate. xml. This file contains information about the function of autoupdateapp.exe, including the network location where the application finds updates. If you do not want to use the location on http: // localhost/, you can change the URL in updatestate. XML to use another update server.

Back to Top

Automatically update the application

Now, there are some great features available for writing automatically updated applications. That is to say, Microsoft developers are currently working to make automatic updates easier and become a natural part of application development. .. NET Framework Version 1.0 provides some inherent basic functions described here, but does not involve deployment functions (see. net zero deployment: security and versioning models in the Windows Forms engine help you create and deploy smart clients ). Finally, it should be noted that the easier it is to install and update an application, the more successful the application is.

To detect and replace updates, Microsoft plans to introduce built-in services in future Windows versions. The BITS Service will remain the basic download mechanism, but more API abstractions will be introduced to simplify the download and security assurance process. Bits will also be extended to include UIS for managing application updates and ease of use.

I hope that one day, the separation line between starting an application and installing the application disappears completely. However, at least today I have been able to write an application that will be updated once installed. This is a very gratifying first step.

For more information, see:

Using Windows XP Background Intelligent Transfer Service (BITs) with Visual Studio. NET

. Net InterOP: Get ready for Microsoft. Net by using wrappers to interact with com-based applications

Applied Microsoft. NET Framework programming by Jeffery Richter (Microsoft Press, 2002)

For background information, see:

. NET and COM: the complete interoperability guide by Adam Nathan (SAMs, 2002)

Jason clark provides training and consulting for Microsoft and wintellect (http: // www.wintellect.com), and is a senior in the Development of Windows NT and Windows 2000 Server. He is co-author of programming server-side applications for Microsoft Windows 2000 (Microsoft Press, 2000. You can contact Jason through a JClark@Wintellect.com.