Browse DevX
Sign up for e-mail newsletters from DevX


Keep your Apps Fresh with the MS Updater Application Block : Page 5

Transform your .NET Windows Forms client applications into self-updating "smart clients" with Microsoft's Updater Application Block.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Configuring the Updater
In the <appUpdater> section you specify the config data for the Updater block itself. As with the <appStart> section, your first point of reference when setting up this section should be the Updater block documentation, but the following tips should save you some time. The easiest parts to configure are the <polling> and <downloader> sections, which are self-explanatory. You should copy the default settings given in the documentation.

You can use a custom validator to ensure that downloaded code hasn't been tampered with by third parties. Doing so is both optional (and configurable with the useValidation attribute of the <application> element); however, omitting any of the <validator> settings generates a configuration exception, so you must include valid configuration data for this section. This is another flaw in the Updater block's design—after all, if you don't want to use validation, why should you have go to the bother of having to generate keys and set up the configuration? That said, it's highly recommended that you use validation for security reasons.

The Updater block comes with a useful and tastefully coloured tool called the Manifest Utility. The tool has a dual function: You use it to create the server manifests for your application's updates, and you can also use it to generate the public and private keys to configure the Updater block's validation functionality. Locate the utility's source (which is in the same place as the Updater code), and add it to your solution. Set the utility as the startup project and run it. Select the File | Generate Keys menu item. Doing that creates two XML files in a location of your choosing.

  • Paste the contents of the public key file into the <key> section of the <validator> element in the AppStart app.config file.
  • You'll paste the contents of the private key XML file into the Key field of the Manifest Utility when you generate the server manifest file. You won't do that just yet, so just save it for now (in a secure place, of course).
Note the following caveats:

  • The Manifest Utility will generate only RSA (Rivest, Shamir, and Adelman) keys, so set your AppStart app.config file to use RSA as the validator (see the Updater documentation on how to do this). You also need to make sure that the RSA assembly is selected in the Manifest Utility's "Validator Class" field when generating the server manifest file.
  • You only need to create the keys once for each application, because the public key is distributed with your application. If you do generate multiple keys, make sure that the public and private keys you're using match properly; otherwise, the validation will fail.
  • You should establish a suitable method for storing the private keys for your applications—treat them as you would any sensitive company secret by storing them in a secure location with limited and audited access.
You use the <application> section for values specific to your application. Unfortunately this is another area where the design is flawed, because you need to specify absolute file paths again. You'll see how to solve the problem later in this article; for now, make sure that any paths or file locations you set in this section are relative links.

The <baseDir> element doesn't appear to be used by the Updater in any meaningful way; the documentation mentions in passing that it is the "the local path to the folder where the application is deployed," but as you're going to see how to convert the Updater to use relative links anyway, you should leave this element blank.

The <xmlFile> is the location of the config file that contains the AppStart configuration settings. The Updater must to be able to locate the config file to determine if your application needs updating, and to update the config file after a successful download occurs. Set the value to the file you are currently editing—the app.config for AppStart—but remember that when you compile the project, Visual Studio converts the filename from app.config to AppStart.exe.config.

The <tempDir> element should contain the name of a temporary directory to which the Updater will download files. The Updater creates and deletes this directory on the fly during downloads, so you don't need to specify a pre-existing location.

<application name="YourAlicationName" useValidation="false"> <client> <baseDir></baseDir> <xmlFile>\AppStart.exe.config</xmlFile> <tempDir>\Application Download Cache</tempDir> </client> <server> <xmlFile> http://YourDeploymentServer/YourRootFolder /YourApplicationUpdateFolder/Manifest.xml </xmlFile> <xmlFileDest>\AppManifest.xml</xmlFileDest> <maxWaitXmlFile>60000</maxWaitXmlFile> </server> </application>

The <server> element contains configuration data for the server manifest file; this is the XML file used to describe the content of each of your application's updates. You'll see how to create the manifest using the Manifest Utility later.

The <xmlFile> element describes the URL of the manifest file. This setting is critical—if you set it incorrectly, the Updater will fail and silently record an error in the event log. You'll generate the Manifest in the next stage, so for now, leave this setting blank or use the example as a template.

The <xmlFileDest> element describes the location to which the manifest will be copied on the client machine. Again, when used "as is", the Updater requires this value to be an absolute file path, but set it to a relative path for now.

The <maxWaitXmlFile> is the default timeout for the manifest file download; leave this at its default setting.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date