The AppLife Engine
When the Update Engine is executed on the client computer, the downloaded update package is parsed to determine the actions that should be executed on the client computer. The Update Engine performs the update in a three stage operation.
Each update action contained in the update package defines methods for each stage the engine executes, as well as a rollback method should an unexpected exception occur during the update process. The engine first iterates the action list, calling the Prepare method on each action. Within the prepare method, each action perform any preparatory and backup activity necessary. Backup activity is performed to facilitate rolling back the state of the client to its initial pre-update state.
Upon successful completion of the Prepare stage, the engine starts over and iterates each action calling the Execute method. Within this method the action performs the update steps. Any activity that must be completed for this update to be successful is performed in the Execute stage. When this stage is completed for all the actions in the update package, the client software is considered updated. Any unexpected exception that occurs prior to completing the Execute stage on all actions will cause the engine to enter into a Rollback process. If the Execute stage completes successfully, the engine moves on to the Cleanup stage.
The Cleanup stage is for removing any temporary files, logging custom activity, or tidying up behind the process. There are no activities critical to the success of the update occurring in this stage. If an unexpected exception occurs in this stage, the stage is aborted, but a complete rollback will not occur. In this event the software is considered successfully updated, but there might be files left in the user’s temporary directory.
In the event of an exception that causes a rollback, the engine starts at the current action and iterates in the reverse order. Each action executes its defined rollback activity. When the rollback process completes, the client software should be back to the same state that existed before executing the update.
Each update package is self-contained and includes the update engine.
A target version is a software version that is eligible to apply a specific published update. When an update is created, its version number is defined along with a list of target versions that can apply the update.
For example, if you are building an update to version 2.0.0.0 of your software, and that update is designed to update version 1.0.0.0 of your software to version 2.0.0.0, then the target list for building the 2.0.0.0 update would include 1.0.0.0.
Special Targets
Many applications have targets that overlap with each update. To simplify these scenarios, there are two special target values that you can use when building updates.
If any previous version of your software can be updated to the current published version, then an <all> entry can be placed into the Target List. This is the default entry on a new project. When the Target List for a published update includes the “<all>” entry, then any software version that is lower than the current publish version can be updated by the update.
When a new update can be applied to all previous versions that are greater than or equal to an earlier version, then the target can be defined as such. A target list value like this can be applied to any software version that is larger than or equal to the target version and smaller than the current publish version number.
For each published update, you can provide a plain text summary of what the update accomplishes for your software. This summary should only contain information about the changes made between this update and the previous version. This text is displayed on the Check for Updates form, and is available to you through the Update Controller API, should you choose to implement a custom updating experience.
When an update will skip one or more versions, the Update Summary text displayed during the update process will include all update summaries between the current version and the update version.
This is text to be displayed to the user when no updates are available. This text is set on an update location scope and is set within the project properties. This text is available through the Update Controller API.
The standard Check for Updates form displays this text when no update is found. By default, the value is empty.
NOTE: The Test flag has been depreciated. The appropriate way to control test deployments is using Access Control Lists and Client Access Keys.
An update can be published for limited availability to testers with a special Test attribute. For a client to discover a test update there must be a specific key in the application app.config file. To enable a client to retrieve test updates, add the following to the host application’s app.config file.
<configuration>
<appSettings>
<add key="Kjs.AppLife.Update.Tester" value="true"/>
</appSettings>
</configuration>
Clearing the test attribute
An update that was published as a test update can be switched to a normal update by managing the location that the update was published to. Select the update from the list of updates, and uncheck the Make this update only available to testers checkbox. Publish the changes and the update will be available to all clients.
Note: You can also switch a normal update to a test update.
AppLife Builder will automatically detect proxy settings in order to publish an update. If you are behind a proxy server and automatic proxy detection fails in your environment, you can set the proxy settings manually from the options form.
Project updates can be managed through AppLife Builder. To manage cloud updates, click the Manage Published Updates…
From the location management dialog, all the updates published to the location can be viewed, and information about each update can be modified and published. The activities that can be performed from this dialog include:
•Removing an update
An update can be removed by selecting the update and clicking Remove this update from the activities list.
•Change targets
The target list of a published update can be modified.
•Modify summary text
The summary text that describes a published update can be modified.
•Edit Access Entries
The defines access for the update can be modified.
•Release a test update
Each update can be defined as a test update or normal update, affecting which clients can discover the update. To release a test update, uncheck the Make this update only available to testers checkbox.
•Modify Custom Data
The custom data for a specific update can be modified.
•Extract an update’s contents
A selected update can be extracted to a local folder.
•View the build log
The build log created as the update was built can be viewed.
•Copy update actions to the clipboard
The update actions are copied to the clipboard, configured as they were when the update was built. The actions can then be pasted into another action list.
Any changes to an update will enable the Publish Changes button. Changes must be published. Any changes not published will be lost when the dialog is closed. Once published, clients will discover the changes when they check for updates.