What is AppLife Update?

AppLife Update is the most flexible application updating solution available for Windows applications. With AppLife Update you can maintain your deployed applications effortlessly, and without administrative support. The AppLife Update API, AppLife Server and AppLife Manager provides the tooling to create the perfect maintenance solution for your applications.

With AppLife Update, you enable your users to obtain updates to your software without asking to first determine which file to download, or whether to uninstall first, or whether to shutdown… These kinds of decisions are often the barriers that prevent users from obtaining updates. All of this is done with a flexible solution that allows you, the software publisher, to control the process. You can:

· Use the AppLife Manager to update your software automatically and without any integration code within your software source code.

· Integrate automatic updating features directly into your application using the AppLife Update API and built-in visual controls.

· Create a completely unique, custom user experience for your application maintenance process.

· Incorporate license or eligibility checks into the update discovery process, controlling the distribution of updates.

· Analyze detailed information on the state of your deployed software.

· Control access to individual update packages and individual users.

· Coordinate between separate running instances of your application during an updating process.

· Elevate privileges during the update process

· Automatically detect proxy settings

· Add custom updating activities easily using your preferred.Net language

· Easily update applications running on Windows 10 / Windows 8 / Windows Vista / Windows 7.

Remove the barriers that prevent your users from updating their software.

The AppLife Update solution is available through two licensing options:

· Hosted Subscription model, where you have access to a cloud-based update publish location and all the AppLife tooling for a low monthly subscription rate.

· Through perpetual, on-premises software licensing.

Visit http://www.kineticjump.com for information on AppLife Update
Send comments on this topic to techsupport@kineticjump.com
©2017 Kinetic Jump Software, LLC


Update Features

With AppLife Update you can quickly and easily implement network based automatic update features into your Windows applications. Some of the primary features of AppLife Update are:

· Create updates that perform almost any action on deployed systems.

· Retrieve updates from any network file server, Http web server, or Ftp server, or AppLife Server

· Supports multiple update locations.

· Control who gets what updates and when.

· Automatically apply updates with no user interaction.

· Apply updates on Off-Peak hours.

· Identify the software version currently installed on your deployed systems.

· Identify and receive notification of failed update attempts.

· Create groups and place deployed installations into your groups, then publish updates that target specific groups.

· Resume downloads upon network errors.

· Supports secure socket layer (https) and passing network credentials

· Automatic proxy detection

· Elevated privileges while executing an update using the AppLife Update windows service or the UAC.

· File patching actions to minimize update size. Patch individual files, or a folder full of files.

· Replace files, register COM assemblies, edit config files.

· Granular control over version updates.

· Update databases on the deployed client.

· Localized update process for en-us, es, ja, ch-ZHT, fr, de, it, and localizable to your culture.

· Distribute Windows Installer based updates.

· Customizable update check and download interface.

· Secure Public-Private key update validation.

· Automatically synchronize new updates versions with the corresponding application assembly version.

· Perform customized updating activity on deployed clients by writing .Net code in a dynamic code update action.

· Automate update creation and publishing into your build process.

· Initial update rollout loading feature.

· Publish test updates that later be released to all clients.

· Includes a merge module to easily distribute the elevated update service with your installer

· Fully documented API.

· Asynchronous update methods.

· Variables that can be used between update actions during an update.

· Detailed update execution logging, including a log viewer, simplifying update development troubleshooting.

· Written entirely in managed code.


Requirements

Client Software Requirements:

To execute updates, and integrate the AppLife API:

Microsoft .Net Framework 2.0 or greater

To use the AppLife Manager:

Microsoft .Net Framework 4.5 or greater

Server Requirements:

To host update packages:

Any File Server share that can be accessed through a file path or UNC path

OR

Any Http Web Server

OR

Any Ftp Server

AppLife Server Requirements:

Microsoft IIS 7.0 or higher

Microsoft SQL Server

.Net Framework 4.5 or higher

Development System:

PC with Pentium II 500 MHz or greater processor

256 MB of Ram Minimum, 1 GB or higher recommended

25 MB of hard disk space for the AppLife Update application and related files

Windows 2010, Windows 8, Windows Vista

.Net Framework version 2.0 or higher


License Agreement

KINETIC JUMP SOFTWARE, LLC.

END USER SOFTWARE LICENSE AGREEMENT

IMPORTANT – PLEASE READ CAREFULLY BEFORE DOWNLOADING, INSTALLING OR USING ANY PART OF THIS INTERACTIVE SOFTWARE PRODUCT. THIS IS A LEGAL DOCUMENT THAT STATES THE TERMS AND CONDITIONS THAT GOVERN YOUR USE OF THE PRODUCT. BY DOWNLOADING, INSTALLING OR USING THIS SOFTWARE, OR BY USING ANY PART OF IT, YOU ACKNOWLEDGE THAT YOU HAVE READ THIS AGREEMENT, UNDERSTAND IT AND AGREE TO BE LEGALLY BOUND BY ITS TERMS.

Kinetic Jump Software, LLC will license this product to you, the licensee (“you” or “Licensee”) only if you accept all of the terms of this end user software license agreement (this “Agreement”). Kinetic Jump Software, LLC provides its software and licenses its use either directly or through authorized dealers. You assume responsibility for the selection of software to achieve your intended results, and for the installation, use and results obtained from the software.

1. Grant of License. Subject to the terms of this Agreement, Kinetic Jump Software, LLC hereby grants to you a non-exclusive and non-transferable license (without any right to sublicense), the software program in machine-readable object code form contained in the media (the “Program”), (ii) the associated written documentation provided by Kinetic Jump Software, LLC (the “Documentation”), and (iii) any updates, revisions or upgrades of the Program or the Documentation provided to you by Kinetic Jump Software, LLC or its authorized reseller (each an “Update”) (the Program, the Documentation and any Update collectively the “Product”). If you receive replacement or backup media containing the Program, you may only use it to in fact replace the primary media and may not transfer the original media to any other individual or computer. All rights not expressly granted to you herein are hereby reserved by Kinetic Jump Software, LLC.

2. Scope of Use. You may install the Product on a single computer for individual use, so long as a licensed user is using the software. In addition, you shall not, nor permit any party to: (i) sell, lease, sublicense, distribute, or otherwise transfer the Product to any person, firm, or entity; or (ii) copy, modify, adapt, translate, decompile, disassemble create or attempt to create, by reverse engineering or otherwise, the source code from any object code supplied hereunder, except you may make one copy of the Program in object code form as supplied, solely for backup or archival purposes. Portions of the Product may not be used independently of the Product. Single Users: Notwithstanding the foregoing, if you have purchased a single-user License, the Product may not be used concurrently on more than one computer or processor unless you purchase additional licenses for each additional concurrent use.

3. Ownership. This is a license agreement and NOT an agreement for sale. All worldwide Intellectual Property Rights that are embodied in or related to the Product are, and at all times shall remain, the sole and exclusive property of Kinetic Jump Software, LLC, whether or not specifically recognized or protected under local laws. For purposes of this Agreement, the term “Intellectual Property Rights” means, collectively, rights under patent, trademark, copyright and trade secret laws, and any other intellectual property or proprietary rights recognized in any country or jurisdiction worldwide, including, without limitation, moral rights and similar rights. You may not delete, alter, cover, or distort any copyright, trademark, or other proprietary rights notice placed by Kinetic Jump Software, LLC on or in the Product.

4. Limited Warranty, Remedies and Disclaimer of Warranty. Kinetic Jump Software, LLC warrants that the media containing the Product shall be free from defects in materials and workmanship under normal use and service for a period of ninety (90) days from the date of shipment to you (the “Warranty Period”). If a defect in such media appears during the Warranty Period, your sole and exclusive remedy and Kinetic Jump Software, LLC’s sole liability under this warranty is the replacement of defective media. To receive a replacement for defective media, you must return the defective media during the Warranty Period to the place of purchase. Except for the foregoing express warranty, the Product is licensed to you on an “AS IS” basis without any warranty whatsoever. No services, training, support or maintenance is provided to you by Kinetic Jump Software, LLC under this Agreement. Kinetic Jump Software, LLC EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, NOT EXPRESSLY STATED IN THIS SECTION 4, INCLUDING WITHOUT LIMITATION, ANY WARRANTY OF TITLE, INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES AND COUNTRIES DO NOT PERMIT THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. THIS WARRANTY GIVES YOU SPECIFIC LEGAL RIGHTS. YOU MAY HAVE OTHER RIGHTS WHICH VARY BY STATE OR COUNTRY.

5. Limitation of Liability. IN NO EVENT SHALL KINETIC JUMP SOFTWARE, LLC BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES (INCLUDING LOSS OF PROFITS) EVEN IF KINETIC JUMP SOFTWARE, LLC HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. KINETIC JUMP SOFTWARE, LLC’S LIABILITY SHALL BE LIMITED IN THE AGGREGATE TO A REFUND OF THE PURCHASE PRICE OF THE PRODUCT THAT GAVE RISE TO THE CLAIM. IN NO EVENT SHALL KINETIC JUMP SOFTWARE, LLC BE LIABLE FOR YOUR COST OF PROCURING SUBSTITUTE GOODS.

6. Export Restrictions. You agree to comply at all times with the provisions of all applicable laws and regulations regarding export controls or technology transfer restrictions of any applicable jurisdiction, including without limitation those of the United States Departments of Commerce and State.

7. Government Rights. Products furnished to the United States or any state or local government are provided on these commercial terms and conditions.

8. General Provisions. This Agreement and its license shall automatically terminate upon failure by you to comply with any of its terms, or if you voluntarily return the Product to Kinetic Jump Software, LLC or the place of purchase. This Agreement will be governed by the laws in force in the state of Minnesota excluding its conflict of law rules and exclusive venue for any litigation shall be in Minnesota. This Agreement will not be governed by the United Nations Convention on Contracts for the International Sale of Goods, the application of which is expressly excluded. If any part of this Agreement is found void and unenforceable, it will not affect the validity of the balance of the Agreement, which shall remain valid and enforceable according to its terms. This Agreement may only be modified in a writing referencing this Agreement and duly signed by an authorized officer of Kinetic Jump Software, LLC. This Agreement constitutes the entire agreement between you and Kinetic Jump Software, LLC relating to the Product, and supersedes any prior purchase order, communications, advertising or representations concerning the Product.


Installation

The AppLife Update solution consists of:

1. The AppLife Update build tools and integration API.

2. AppLife Server

3. AppLife Manager

The latest software setup files can be downloaded from http://www.kineticjump.com/downloads.aspx

More:

Installing AppLife Update

Installing AppLife Server

Installing AppLife Manager


Installing AppLife Update

1. Run the AppLife Update Setup msi file

2. Generally, you can accept all the default options. You can choose to install the AppLife Update application to a different folder.

Note: The administrative privileges are required to install AppLife Update.

Upon installation, AppLife Update will operate fully featured for a period of thirty days. To use AppLife Update beyond thirty days, you must purchase a user license. You can purchase a license online at http://www.kineticjump.com/buy.aspx


Installing AppLife Server

1. Verify the Server Requirements.

2. Download the AppLife Server installation file. This is a compressed folder (zip).

3. Extract the installation files to a local folder.

4. Inside the root of the installation folder, you will find an Instructions.txt file. Open this file and review the detailed installation instructions.


Installing AppLife Manager

AppLife Manager ships with AppLife Server and requires the use of AppLife Server for update publication.

1. Download the AppLife Manager Windows Installer(Msi) from your AppLife Server or the AppLife Cloud

http(s)://yourserver/GetAppLifeManager
https://www.applifeupdate.com/GetAppLifeManager

2. Run the AppLifeManager.msi setup file

3. The AppLife Manager resides in the System Tray. Click the System Tray icon to view the Manager Window.

4. Add your server to the AppLife Manager configuration.
Note: This step requires administrative privileges

When adding your server, enter the server address, the appropriate Client Access Key, and if you are using the AppLife Update cloud, enter your Subscription ID.


Quick Starts

Welcome to AppLife Update! AppLife Update provides incredible flexibility in implementing an update process within your software application. You can choose to use the AppLife Manager Windows service or integrate directly into your application with four built-in and ready to use update processes. Or take advantage of the flexibility provided by the AppLife Update API and easily develop your own updating user experience.

With your deployed maintenance process looking and behaving the way you want, the actions that you can utilize in maintaining your deployed installations from one version to the next is just as flexible. Many common Windows application updating activities, such as file and registry manipulation, come ready-to-use. Just drag, drop and configure them in your action list. And if you don’t find a built-in action that meets your needs, you can use the Dynamic Code Action to write your own .Net updating code, or create your own reusable custom actions. We’ll show you how.

Within this Quick Start guide, we demonstrate how to use AppLife Update to maintain your applications. Using the AppLife Manager, a direct integration approach, or a customize AppLife Update implementation to meet your specific updating requirements.

1. AppLife Manager
This quick start will walk through the process of creating a new application on an AppLife Server, setting up an AppLife Project to publish updates for the application, and publishing an initial update that will install the application on deployed systems running AppLife Manager.

2. Simple
The simple quick start application implements the AppLife Update solution in its simplest form. We enable a brand new WinForms application for updating with AppLife Update. This implementation might just be all that you need.

3. Simple – WPF
The simple WPF quick start uses the AppLife WPF updating control to implement updating features into a WPF application.

4. Custom Forms
The Custom Forms application utilizes methods and events on the Update Controller to check for, download, and apply an update. The application replaces the built-in updating user interface with a completely custom one. The tasks that you learn in this quick start can be used to design and implement many different updating processes.

5. Custom Actions
This example demonstrates how to create a custom action, as well as a corresponding custom action builder and custom action editor to provide an Update Action that will perform a text file search on the deployed client that is being updated for a designated regular expression. The results are then further manipulated with customized .Net code using a Dynamic Code Action.

After you have reviewed these quick starts, you will be well prepared to implement AppLife Update into your own applications. Please refer to this help manual in its entirety, as well as the AppLife Update API reference, which can be accessed through the AppLife Update Help menu or Online, for more information on using the AppLife Update product to integrate an update process, and deploy software updates into your own applications.

To work through these quick starts, you will need to have AppLife Update and Visual Studio installed on your computer. For the AppLife Manager walk through, you will need access to an AppLife Server or an AppLife Update Cloud subscription.

If you have not already done so, install AppLife Update to your local system.

NOTE: All of the Quick Starts come with a precompiled version 2.0.0.0. This precompiled version is located in the CurrentVersion folder. The update location in the precompiled version does not match the location to where you extracted the Quick Start. As a result, after successfully updating to version 2.0.0.0, subsequent check for update attempts will result in a message that the update location can not be found. To correct this in your Quick Start, change the Update Location on the Update Controller within the Visual Studio project to match the Update Location of the Make Update project.

Extracting the Quick Starts

The Quick Starts are packaged with the install of AppLife Update. You can extract any of the Quick Starts into a new folder by selecting a Quick Start from the Start Page or the Help > Quick Starts menu.

Once extracted, the extraction location will contain a completed Visual Studio project, a corresponding AppLife Update project, and an updates folder with a compiled update ready to go. You can open the Visual Studio project and the AppLife update project file to view the completed quick start. This solution can act as a reference as you read through this accompanying documentation.

More:

AppLife Manager Quick Start

Simple Quick Start

Custom Forms Quick Start

Custom Action Quick Start

Simple WPF Quick Start


AppLife Manager Quick Start

1. Create an application on your AppLife Server, or provision a new application on the AppLife Cloud.

Note the Enable AppLife Manager Integration checkbox. The AppLife Manager client service will not “see” this application until this setting is enabled. The default value is disabled. Leave this setting disabled until the configuration of this application is completed and we are ready to expose the application to your deployed clients.

The default Client Access setting is for anonymous access. This can be changed under the Client Access tab. We will come back to this later in the walkthrough. Initially, we’ll stay with anonymous access.

AppLife Manager settings can be configured under the Manager Settings tab. For initial configuration, it is better to walk through the New Project wizard within the Make Update build tool. This process will synchronize the update project file with the server settings.

2. Launch AppLife Make Update and select to create a new project…

Select AppLife Manager Maintained Application and click Next.

Enter your server URL and publishing credentials, then click to login. Once logged in, click Next to continue.

You will see a list of all applications for which you are a publisher, and has not yet been configured to use AppLife Manager.

Select the application and click Next to continue.

The next page in the wizard allows you to configure most of the settings that govern how the application maintenance process will operate within AppLife Manager.

Application Directory
This is the directory that the AppLife Manager expects to find or install the application to. For this example, we are going to modify the default value to be %ProgramFiles%\AppLifeManagerExample

 Process Name
The process name value is used by the AppLife Manager to identify running instances of the application being maintained, and if necessary, stop the process(s) before applying updates. The download for this Quickstart includes version 1 and 2 of a simple example. This example process is named ExampleApplication, so we will set the value to that.

Primary Executable
Identifying the primary executable allows AppLife Manager to launch the application and use the assembly/file version of the primary executable for versioning. This value can include a path relative to the identified Application Directory. For this example, the primary executable will be located in the Application Directory and will be named ExampleApplication.exe

Apply Updates Automatically
AppLife Manager will download and apply updates without any user intervention.

Update Recheck Frequency
The default frequency is to check for updates once a day (every 1440 minutes). We’ll set this value to the lowest allowed (5 minutes) for testing and experimentation.

For the rest of the settings, we’ll leave the defaults.

Click Next

Access control can be defined using Access Control Lists and Client Access Keys. The time window that updates are allowed can also be defined. For now, we’ll leave the defaults.

The AppLife Update API optionally allows applications to be notified and interact with the AppLife Manager and applying updates. This example will not integrate.

Click Finish to apply the settings to the application.

3. With the New Project wizard completed, the application is configured on AppLife Server and we have an AppLife Update project file ready to start creating and publishing updates for the application. A few things to note here are:

a. The Application is still not enabled for AppLife Manager within the server configuration. We can toggle that when we are ready for deployed AppLife Managers to start “seeing” the application.

b. The newly created AppLife Update project contains the Private/Public key pair that is needed to create updates for this application. Backing up this file is highly recommended.

Notice that the update project contains a Set Update Version action. This action was added by the New Project wizard because the application is configured to use the AppLife Manager configuration file for version identification. This action will update the AppLife Manager configuration file as updates are applied.

Deploying the application

To deploy this application we are going to create an application that will target the scenario where an AppLife Manager deployment first discovers the application. In this scenario the AppLife Manager will have an effective version number of 0.0.0.0. Our first update will install version 1.0.0.0 of our example application and will target any clients with a version number less than 1.0.0.0.

Actions to Include
We will include an action that will:

1. Add the application assemblies to the identified application directory

2. Add a shortcut to the application in the All Users profile

3. Update the Version setting

Add an Add & Replace Files action to the update by double clicking or dragging the action from the Action Palette onto the action list.

Add the version 1.0.0.0 executable and config file from the associated download.

ExampleApplication.exe

ExampleApplication.exe.config

The default Target Client Folder is the configured application directory. If the folder doesn’t exist on the deployed client, it will be created. Remember that we configured the %ProgramFiles%\AppLifeManagerExample folder as the application directory. This folder will be created when this first update is applied.

Add a Create File Shortcut action to the update action list

We will place the shortcut in the all users start menu.

Set the Shortcut location and the shortcut target

Build and Publish the Update

Click the Create an Update… button to start the publish wizard

Set the update version to 1.0.0.0 and the Versions to Update to Any Previous Version.

Click Next. The second wizard screen allows you to publish the update for specific Access Control Lists and set a few other features. We’ll accept the defaults and publish the update for general accessibility.

Click the Build Button to build and publish this new update.

With the update published, the application is ready for the AppLife Manager to discover, download and apply the update. Because the application is configured for anonymous access, any AppLife Manager configured to check this server for updates will find the application and install it. To enable this application, log into your server and toggle the Enable AppLife Manager Integration option.

With the application enabled, AppLife Manager can now “see” the application.

Building and Publishing an update to Version 2.0.0.0

The update to version 2.0.0.0 will no longer need the shortcut be placed, so lets remove that action.

Update the Add & Replace Files action to include the new version 2.0.0.0 files, then build update version 2.0.0.0 by clicking on the Create an Update… button.

With version 2.0.0.0 created, the AppLife Manager will automatically discover and apply the update to version 2.0.0.0. If version 1.0.0.0 is running, the user will be prompted before the update is applied. If running instances are shutdown, they will be restarted after the update completes under the same user context as was originally running under.


Simple Quick Start

The simple quick start application implements the AppLife Update solution by using the UpdateDisplay Windows Forms control. We’ll walk through enabling an existing WinForms application for AppLife Update. To update the application, a single Add and Replace files action is used.

1. Add an UpdateDisplay Control to the Main Form of the Application.

Drag and drop an UpdateDisplay control from the WinForms toolbox in Visual Studio onto the application’s main form. This control can be found on the AppLife Update tab. The UpdateDisplay control provides an in-line asynchronous check for updates, download, and user notification. The control also has a details pop-up pane. You can use this control from the main form of an application to completely manage the update process. There are many customizations available through the properties of this control. When an UpdateDisplay control is placed on a form, an UpdateController control is also added. The Update Controller performs all of the actual work of the update process, and the UpdateDisplay provides a user experience. You can switch user experiences by adding one of the alternative display controls and assigning the existing update controller to the control’s UpdateController property. Multiple visual controls can utilize the same update controller.

See the User Experience Options topic for information on the other built-in update user experiences available.

Note: Visual Studio Express Editions will not have AppLife Update controls pre-populated in the toolbox. These controls can be manually added to the toolbox, and then dragged onto your form. To manually add the controls, select to Choose Items… from the toolbox context menu, then select the UpdateDisplay control from the .Net Framework Components list.

2. Set up a new AppLife Update project.

Click the UpdateDisplay control smart tag, and select to Set up a new project.

To set up a new project, specify:

1. Where will your updates be hosted?

2. How would you like to control versioning?

3. Will your updates require permissions elevation?

You can utilize any http, ftp, UNC or file path location to host your updates. There are no server requirements, except that your application must be able to connect to this location.

Note: It is common to use a different path to publish updates. Ftp is commonly used to publish, while http is used to retrieve updates.

By using Assembly Version for versioning, the host executable assembly version determines the client version, and is used to determine which updates are available for the application. By selecting to set the version manually, the Version property of the Update Controller will determine the version of the client. Using manual versioning is often used in customized updating implementations to provide flexibility. For most .Net applications, assembly versioning is the best choice.

The permissions that your update process requires is determined by where the application is installed on the deployed system, and the security posture of the deployed system environment. Applications that are installed into the Program Files directory and started by a user with limited permissions will not be able to be updated without permissions elevation. You can choose no elevation, UAC elevation, or elevation using the AppLife Update Windows Service. The AppLife Update Windows Service can securely elevate the permissions of the update process to run as the local system account, allowing limited users to update your software without administrative support. If you utilize the Windows Service, this service will need to be deployed with your application. Administrative permissions are required for initial installation of the service as well as the registration of each application that will use it. See deploying the AppLife Update Windows Service for more information.

3. Build an Update

When you complete the setup, a new AppLife Update project is created, and the Update Controller on the application main form is synchronized with this project. This can be confirmed by comparing the Application ID, Public Key, and Update Location properties of the Update Controller with the project settings. These settings must match in order for your application to successfully apply updates created by this project.

As this project was created, an Add & Replace Files action was added to the project for you. This update action will replace the host executable, and any Visual Studio project referenced assemblies from the solution as the update executes on deployed systems. You can add additional files to this action, or use any other update action in the Action palette by modifying the action list.

To build an Update:

a. Build the executable in Visual Studio. Don’t forget to set the proper version number before building the executable. Make Update will detect the assembly version of the host executable (your application), and this will determine the version number of the update being created.

b. In Make Update, Click the Create an Update button…
This will launch the create update wizard.

The update version being created is 2.0.0.0. This is detected from the host executable.

This update is available for any previous version of this application. If the actions in the update action list are configured to expect a specific version, you can change the Versions to Update to target a specific version. You can also target all versions greater than a specific version, or a discrete list of previous versions.

Summary text describing the update can be provided. This text will be displayed by the update user experience and is also available through the Update Controller API.

Custom Data provides a method to pass information to your update process. Information provided here is available to your application through the Update Controller API.

Note: The list of versions to update, summary text, and custom data can be modified after an update has been created by managing the update location that the update is published to.

Click Next>

On the next page, you can select from one or more update locations to publish the update to. If your update location requires credentials, you can provide them here, or be prompted as the update is actually transferred. When updates are present at the location, they are displayed in the list on the right.

The update can be designated as a test update by checking the Make this update only available to testers checkbox. When this box is checked, clients who will discover this update must have a specific value in their app.config file. See Testing updates for more information. This value can be modified by managing the update location that the update is published to.

Click Build > to build and publish the new update.

4. Applying the New Update

The newly created update can now be used to update any previous version of the application to version 2.0.0.0. To test this, we’ll change the application version in Visual Studio back to version 1.0.0.0, build the application, and then run it.

a. Change the assembly version back to 1.0.0.0

b. Start debugging the application in Visual Studio.

The update process is started automatically.

Applying the update…

The host application is closed and the AppLife Update engine performs the actions defined in the update action list.

The update completes and the host application is restarted as version 2.0.0.0. An update check is performed, but this time the application is up-to-date.

The Custom Forms Quick Start walks through using the Update Controller API to create a completely customized user experience.

The Custom Actions Quick Start walks through creating completely custom update actions, allowing you to perform any updating activity during an update.


Custom Forms Quick Start

The Custom Forms application utilizes methods and events on the Update Controller to check for, download, and apply an update. The application replaces the standard update engine user interface (displayed to the end-user as an update is being executed) with a completely custom UI. The concepts that you learn in this quick start can be used to design and implement completely customized updating user experiences.

This Quick Start does not use any built-in user interface forms at all. It includes totally custom forms that utilize the methods and events of the Update Controller to perform all of the update related tasks. Specifically:

1. A custom check for updates form

This form uses the CheckForUpdateAsync method and the CheckForUpdateCompleted event to check for updates.

2. A custom download updates form

This form uses the DownloadUpdateAsync method, The DownloadUpdateProgressChanged event, and the DownloadUpdateCompleted event to download a discovered update.

3. Once downloaded, a button is enabled that allows the user to apply the update.

4. A custom Update Engine user interface form

This form is displayed by creating an assembly that includes a class that implements the Kjs.AppLife.Update.Engine.Core.IUpdateUI interface.

Enabling the Application

The application is enabled for updates by following the same procedure outlined in the Simple Quick Start. You add an Update Controller to the host application source code, and then use the Set up a new project utility. If you have not yet reviewed the Simple Quick Start, we recommend that you do so before continuing.

Coding the Update Process

Instead of using a built-in user experience as we did in the Simple Quick Start, a custom user interface is implemented here.

1. Create a folder under My Documents and name it Custom Forms.

2. Extract the Custom Forms Quick Start in your preferred language by clicking on the link on the AppLife Make Update start page or the Help > Quick Starts menu.

3. Open the CustomForms.sln Visual Studio solution.

4. Start the solution. When the main form opens, click the Check for Updates button. You will see that the entire user interface of the update process is completely customized.

Checking for Updates

The AppLife Update Controller provides synchronous and asynchronous methods to check for updates. Both methods perform an update discovery task by checking the designated update location for updates. If an update is available for the current version, the CurrentUpdate property of the Update Controller will contain an UpdateInformation structure with information about the available update. If an update is not available, the CurrentUpdate property will be empty or null.

The synchronous CheckForUpdate method returns true if an update is found.

The asynchronous CheckForUpdateAsync method will raise the CheckForUpdateCompleted event when the check is complete.

From AppLife Make Update, click on Help>API Reference and browse to:

Kjs.AppLife.Update.Controller Namespace

UpdateController class

UpdateController Methods

CheckForUpdateAsync Method

Review the documentation for this method. This is the method this Quick Start uses.

5. In Visual Studio, open the Form1 source code file of the Custom Forms project. The Check For Updates button handler contains code that opens the custom CheckForUpdatesForm

6. The CheckForUpdatesForm contains the relevant code that performs the update check using the Update Controller.

In the constructor of the form, we subscribe to the CheckForUpdateCompleted event and we call the CheckForUpdateAsync method.

7. Once the form is opened and before the CheckForUpdateCompleted event occurs, an animated gif is displayed to the user. The user can cancel the check or close the form. The Download button is disabled until an update is found.

You can cancel an ongoing asynchronous operation by calling the UpdateController.CancelAsync method.

8. Looking at the mUpdateController_CheckForUpdateCompleted event handler, we can see that we interrogate the CheckForUpdateCompletedEventArgs to determine the results of the update check. First we see if the operation was cancelled, then we look for any errors that might have occurred. If all is good, we can look at the Result property. If an update was found we enable the Download button and do some work to show the user what was found. Notice that we look at the CurrentUpdate property of the Update Controller. If no update was found, the Current Update property would be empty or null.

This event handler is guaranteed to be executed on the same thread that started the asynchronous check. You don’t have to worry about any thread marshalling when using these asynchronous methods. That is all done by the Update Controller.

Notice how little work that was actually involved with the update process. Most of the code that is present involves handling the form and how we want to interact with the user.

One more item to note is the UpdateFound event. Though not used in this Quick Start code, this event allows you to interrogate the update information, and use local client state information, such as your application licensing status, in order to select from alternate updates that might be available. The update can also be canceled, which prevents an update from being discovered. The AppLife Update API documentation contains more information on this event.

Now let’s go download the update.

Downloading an Update

Once an update is found, the CurrentUpdate property contains all the information we need to download, validate, and apply the update.

The Download Update button click handler instantiates and shows a new DownloadUpdateForm.

9. Look at the constructor of the DownloadUpdateForm. Much like the CheckForUpdate form, we subscribe to events and call an asynchronous download method. This time we subscribe to an additional event that sends download progress updates.

We subscribe to the DownloadUpdateProgressChanged event and the DownloadUpdateCompleted event.

Then we call the DownloadUpdateAsync method.

10. When a progress event occurs, we update the text of the information label on the form. Again, this handler is guaranteed to execute on the calling thread, so as long as the initial DownloadAsync method was called on the UI thread, you can safely modify UI controls. The thread synchronization work is done for you in the Update Controller.

11. When the download completed event is handled, much like when the check for update was completed, we check to see if the operation was cancelled and check for any errors. Once the update is downloaded, the controller can validate and apply the update. With the download completed and validated, we enable the Install Now button.

Validate & Apply the Update

Validating the downloaded update uses the public key from the Update Controller and the signature of the update package contained in the Director to check the downloaded update package. You can perform validation manually using the UpdateController.ValidateUpdate method.

The downloaded update can be applied using the ApplyUpdate method. This method also performs validation prior to execution of the update.

Applying an update shuts down this instance as well as all other instances of the application being updated so that its files and assemblies can be replaced. Though this Quick Start does not do so, you can subscribe to the UpdateStarted event of the UpdateController. This event will be raised on every running instance of the hosting application. You can perform any work necessary prior to shutdown, and you can cancel the update from any instance of the application. If all instances cannot be shutdown, the update will abort itself.

12. Look at the installButton_Click method. Notice that we validate the update manually before calling ApplyUpdate. Alternately you could call ApplyUpdate and catch any Kjs.AppLife.Update.Controller.ValidationException exceptions.

Like the Simple Quick Start, the AppLife Update project uses the Add & Replace file action to replace the single CustomForms.exe file.

13. To customize the Update Engine user interface, we will create a new .Net assembly (.exe or .dll) and create a class that implements the Kjs.AppLife.Update.Engine.Core.IUpdateUI interface. Notice the Custom Update UI project in the quick start solution.

From AppLife Make Update, click on Help>API Reference and browse to:

Kjs.AppLife.Update.Engine.Core Namespace

IUpdateUI Intererface

IUpdateUI Members

This interface is implemented by the Form1 class of the Custom Update UI project. The class code has lots of code comments that provide details on the interface and how it is implemented. To summarize:

· The custom user interface is displayed in the IUpdateUI.Open() method

· The user interface is refreshed in the IUpdateUI.Update() method

· Update completion notification is provided from the IUpdateUI.Finish() method.

· The Custom UI informs the Update Engine of its activity by raising events.

· When the User Interface is closed, the Closed event is raised informing the update engine that it’s okay to shutdown and complete the update process.

· The User Interface can cancel, pause or resume the update by raising events.

14. The customized user interface is imported into AppLife Make Update, making it available to be packaged into an update. This is accomplished through the project settings dialog. Project -> Settings menu option.

With the customized update engine user interface present, all future updates will utilize the imported user interface.

This Quick Start highlights the manual methods on the Update Controller that allows you to check for, download, and apply updates under a very flexible architecture. A customized update engine user interface was also presented. We used forms to control the process, but no forms are actually necessary. You can mold the update discovery and download features into any visual or non-visual process that best fits your application and your users.


Custom Action Quick Start

This example demonstrates how to create a custom action, as well as a corresponding custom action builder and custom action editor to provide an Update Action that will perform a text file search on the deployed client that is being updated for a designated regular expression. The results are then further manipulated with customized .Net code using a Dynamic Code Action.

Custom actions in AppLife Update allow you to execute custom .Net code during the execution of an update package on the deployed client. Authoring a custom action and adding it to an update consists of:

· Creating a .Net class that inherits from the UpdateAction class

· At a minimum, implement a parameterless constructor, Execute method, and a RollbackExecute method on the class.

· Compile the custom action assembly

· Add the assembly to the collection of custom action assemblies in AppLife Make Update

· Add the action to the project list.

Custom Actions can be further enhanced by creating a custom action builder. With a custom action builder, you can intervene during the update build process, validate the properties of a custom action, manipulate the action properties as the project file is saved, and launch a customized update action editor.

The update scenario demonstrated in this Quick Start is to migrate setting from a text-based configuration file that version 1 of the example application uses, to an xml-based configuration file that version 2 of the example application uses.

1. Review how the AppLife Update Engine operates. Our custom actions operate in this context.

2. When added to the Make Update custom action assemblies list, our custom actions are configured within AppLife Make Update and persisted within the AppLife Update project file by interacting with public properties on the custom action classes. Any public properties that are implemented will be configurable from AppLife Make Update and persisted with your project.

3. Review the Update Context object. We will use the context object’s SharedProperties property to pass information between the actions in this example.

Architecting our Custom Actions

We are going to create a custom action that searches a designated text file for a line that includes a designated regular expression. If the regular expression search finds a match, the entire line within the text file will be placed in a designated Shared Property within the Update Context Shared Properties collection so that it is available for further processing by the update. This custom action is named Search File Action.

Further processing will be performed by a second custom action that is defined within a built-in Dynamic Code Action . Dynamic Code actions provide the ability to quickly create customized update activity.

Our Search File Action is further refined by adding a custom action builder. In the custom action builder, we’ll validate the properties of the action, preventing Make Update from building the action with invalid input information. We’ll also create and launch a custom update editor. Our editor will replace the default property grid editor and provide an intuitive interface as well as validation feedback for the update designer.

4. Open the Custom Actions solution with Visual Studio. Within this solution you will find two projects. The Custom Actions application and the Actions class library.

5. Notice that the Actions project contains a reference to the Kjs.AppLife.Update.Engine.Core assembly and the Kjs.AppLife.Update.Engine.Core.Design assembly. These assemblies are located in the [InstallDir]\PublicAssemblies folder where AppLife Update is installed. The core assembly contains the UpdateAction base class from which all custom actions are derived. The design assembly contains the ActionBuilder base class used provide a custom action builder and editor.

Creating the SearchFileAction

The SearchFileAction derives from UpdateAction. It contains an empty parameter-less constructor. This constructor is necessary, as without it, the Update Engine could not create an instance of this action.

There is a public FileName property that is used to store a path (relative to the deployed client application directory) to a local text file that will be searched when the update action executes.

There is a public Regex property that is used to store the regular expression that will be searched for within the identified text file.

There is a public SharedPropertyName property that identifies the key name of the Shared Property that will store the results of the regex search.

Adding these properties makes this action easily re-usable in other projects.

6. The Execute method of this action backs up the value of the designated Shared Property (if it exists) so that it can be rolled back if the update fails. Then, the designated text file is searched.

The user is kept informed by utilizing the base class OnProgressChanged method, and the update execution log file is updated using the UpdateContext Log property.

7. The RollbackExecute method restores the original value of the Shared Property. No other action is necessary to rollback the execution of this action.

To control the AppLife Make Update palette location of this action, attributes are placed on the class declaration.

[DisplayName("Search File")]

[Description("Search a text file for a regular expression and store the matching line in a shared property.")]

[Category("Files & folders")]

These attributes result in:

These attributes cleanly present the custom action within the Make Update application, however they are not required. If they were omitted, the action would be in a category named “Misc” with an action name that matches the name of the class.

Creating the SearchFileActionBuilder class

Note: See Custom Action Builder.

Implementing an action builder for the SearchFileAction will provide validation functionality as well as launch a customized action editor user interface. The custom action editor is assigned to the action by adding a ActionBuilder class attribute to the action class.

[ActionBuilder(typeof(SearchFileActionBuilder))]

public class SearchFileAction : UpdateAction {

8. Implement ValidationActionCore
This method checks to ensure that a search file name, regular expression, and shared property key name is provided. If any of these properties are empty, Make Update will not build the project, and the action is adorned as being invalid.

9. Implement StartEditingAction
In this method, the custom editor is instantiated and shown, replacing the default property grid editor.

Creating the SearchFileActionEditor

A custom action editor is a Windows Forms User Control. When a custom action editor is created, the corresponding Action Builder instance is passed into the editor as a constructor parameter. We maintain a reference to the Action Builder and by extension, the Update Action. This reference is used to manipulate the Update Action from the custom editor.

The SearchFileAction editor provides textboxes and checkboxes to enter the necessary information required to configure the update action behavior.

Adding the actions to your action list

Once the Update Action and supporting classes are compiled into a .Net assembly, we can add the assembly to the custom action assemblies list.

Open the Project Settings dialog from the Project menu. Then open the Custom Actions tab.

Add an assembly by clicking the Add an assembly button and browsing to your custom assembly.

Note: AppLife Make Update loads the custom action assemblies that are used by the project. When a custom action assembly is loaded, the assembly is locked by Make Update. This could cause Visual Studio builds to fail if you reference your custom action assemblies in Make Update from the Visual Studio build location. To unload the assemblies you will need to close AppLife Make Update.

Once an assembly has been added, its custom actions are placed in the action palettes and are available to be placed into the action list. Custom actions can also be made available globally to all Make Update projects by placing the assembly into the Make Update AppDir/Custom Actions folder. This folder is typically located at:

C:\Program Files\AppLife Update\MakeUpdate\CustomActions

Update the Example Application using the Search File Action

Version 1 of the example application utilizes a text-based settings file. Version 2 utilizes an Xml-based settings file. In order to update a deployed Version 1, our update must migrate a couple of settings from the old to the new settings files. To do this, we are going to utilize the Search File action, along with a few built-in Update Actions.

Step 1 – Find the settings of interest within the old text-based settings file

Step 2 – Parse the settings that are found using a Dynamic Code Action

Step 3 – Copy the new application assemblies and the new Xml Settings file using an Add & Replace files action.

Step 4 – If previous settings were successfully extracted from the existing settings file in Steps 1 and 2, then update the newly placed Xml file using a Change Xml Node action. Note: These actions are conditionally executed.

Step 5 – Delete the old settings file using a Delete files action.

Our update action list looks like this:

Search File Editor:

This action will search the OldSettingsFile.txt file for the line that has the Setting1=value, and if found, the entire line will be placed in a Shared Property named Setting1.

Parse the Settings values using a Dynamic Action:

The built-in Dynamic Code action provides a simpler method to add a custom action to an update. To demonstrate this method, a Dynamic Code Action is used to parse the value out of the line that was found by the custom Search File Action.

The Dynamic Code action allows you to write a custom action directly within Make Update. The action is compiled as the update package is built. This action will read the Shared Property that the Search File action set, and parse the value. The Shared Property is then updated to include only the value of the setting.

Copy the Application Assembly and new Xml Settings File

A built-in Add & Replace files action places the new files on the deployed client.

Updating the new Xml File

With the NewSettingsFile.Xml now present and populated with default values, the update must replace the default values with the entries from the previous text-based settings file. To accomplish this, a built-in Change Xml Node action is used.

Conditional Execution:

This action has a condition expression set. The action is only executed if the shared property “Setting1” is not empty.

If the Shared Property “Setting1” is not empty, the NewSettingsFile.xml file is updated using an XPath query and the value of the Shared Property.

Deleting the old Settings File

The final step in this update process is to use the built-in Delete File action to remove the old settings file.

Summary

Creating custom actions for use with AppLife Update is extremely easy. You are not limited to just the standard AppLife Update actions. Custom actions allow you to easily define and execute .Net code during your software updates.

Reference the API Reference documentation

Browse the Kjs.AppLife.Update.Engine.Core namespaces for more information on custom actions.


Simple WPF Quick Start

The simple WPF quick start demonstrates how to utilize AppLife Update within a WPF application. This example utilizes the WPF UpdateDisplay control.

1. Add an UpdateDisplay Control to the Main Window of the WPF Application.

Drag and drop an UpdateDisplay control from the WPF toolbox in Visual Studio onto the application’s main window. This control can be found on the AppLife Update tab. The UpdateDisplay control provides an in-line asynchronous check for updates, download, and user notification. The control also has a details pop-up pane. You can use this control from the main window of an application to completely manage the update process. There are many customizations available through the properties of this control. When an UpdateDisplay control is placed on a window, a reference to the Kjs.AppLife.Update.Wpf.dll and Kjs.AppLife.Update.Controller.dll is added to the Visual Studio project. In addition, a “kjs” namespace is declared on the window.

See the User Experience Options topic for information on the other built-in update user experiences available.

Note: Visual Studio Express Editions will not have AppLife Update controls pre-populated in the toolbox. These controls can be manually added to the toolbox, and then dragged onto your form. To manually add the controls, select to Choose Items… from the toolbox context menu, then select the UpdateDisplay control from the WPF Components tab.

2. Set up a new AppLife Update project.

Click the control’s Set up a new project adorner.

To set up a new project, specify:

1. Where will your updates be hosted?

2. How would you like to control versioning?

3. Will your updates require permissions elevation?

You can utilize any http, ftp, UNC or file path location to host your updates. There are no server requirements, except that your application must be able to connect to this location.

Note: It is common to use a different path to publish updates. Ftp is commonly used to publish, while http is used to retrieve updates.

By using Assembly Version for versioning, the host executable assembly version determines the client version, and is used to determine which updates are available for the application. By selecting to set the version manually, the Version property of the Update Controller will determine the version of the client. Using manual versioning is often used in customized updating implementations to provide flexibility. For most .Net applications, assembly versioning is the best choice.

The permissions that your update process requires is determined by where the application is installed on the deployed system, and the security posture of the deployed system environment. Applications that are installed into the Program Files directory and started by a user with limited permissions will not be able to be updated without permissions elevation. You can choose no elevation, UAC elevation, or elevation using the AppLife Update Windows Service. The AppLife Update Windows Service can securely elevate the permissions of the update process to run as the local system account, allowing limited users to update your software without administrative support. If you utilize the Windows Service, this service will need to be deployed with your application. Administrative permissions are required for initial installation of the service as well as the registration of each application that will use it. See deploying the AppLife Update Windows Service for more information.

3. Build an Update

When you complete the setup, a new AppLife Update project is created, and the Update Controller on the application main form is synchronized with this project. This can be confirmed by comparing the Application ID, Public Key, and Update Location properties of the Update Controller with the project settings. These settings must match in order for your application to successfully apply updates created by this project.

As this project was created, an Add & Replace Files action was added to the project for you. This update action will replace the host executable, and any Visual Studio project referenced assemblies from the solution as the update executes on deployed systems. You can add additional files to this action, or use any other update action in the Action palette by modifying the action list.

To build an Update:

a. Build the executable in Visual Studio. Don’t forget to set the proper version number before building the executable. Make Update will detect the assembly version of the host executable (your application), and this will determine the version number of the update being created.

b. In Make Update, Click the Create an Update button…
This will launch the create update wizard.

The update version being created is 2.0.0.0. This is detected from the host executable.

This update is available for any previous version of this application. If the actions in the update action list are configured to expect a specific version, you can change the Versions to Update to target a specific version. You can also target all versions greater than a specific version, or a discrete list of previous versions.

Summary text describing the update can be provided. This text will be displayed by the update user experience and is also available through the Update Controller API.

Custom Data provides a method to pass information to your update process. Information provided here is available to your application through the Update Controller API.

Note: The list of versions to update, summary text, and custom data can be modified after an update has been created by managing the update location that the update is published to.

Click Next>

On the next page, you can select from one or more update locations to publish the update to. If your update location requires credentials, you can provide them here, or be prompted as the update is actually transferred. When updates are present at the location, they are displayed in the list on the right.

The update can be designated as a test update by checking the Make this update only available to testers checkbox. When this box is checked, clients who will discover this update must have a specific value in their app.config file. See Testing updates for more information. This value can be modified by managing the update location that the update is published to.

Click Build > to build and publish the new update.

4. Applying the New Update

The newly created update can now be used to update any previous version of the application to version 2.0.0.0. To test this, we’ll change the application version in Visual Studio back to version 1.0.0.0, build the application, and then run it.

a. Change the assembly version back to 1.0.0.0

b. Start debugging the application in Visual Studio.

The update process is started automatically.

Applying the update…

The host application is closed and the AppLife Update engine performs the actions defined in the update action list.

The update completes and the host application is restarted as version 2.0.0.0. An update check is performed, but this time the application is up-to-date.

The Custom Forms Quick Start walks through using the Update Controller API to create a completely customized user experience.

The Custom Actions Quick Start walks through creating completely custom update actions, allowing you to perform any updating activity during an update.


License Management

AppLife Update is licensed per builder. A builder is defined as a person or process that interacts to build and publish updates using the AppLife Update tools.

The Update Controller assembly and features can be distributed royalty free with your applications, so long as the updates being created for the application are created by a licensed user.

Our licensing model is based on users who actually build update packages. With AppLife® Update, your costs do not increase with more end users, project developers, or even applications. You simply purchase a license for your team members who build update packages. Furthermore, all licenses include one year of premium technical support and software upgrades.

Single Builder License

An AppLife® Update Single Builder license permits one user to install and use the AppLife Update tools on a single computer. A licensed builder can build updates for an unlimited number of applications. The client components deployed with your software can be distributed royalty-free to an unlimited number of clients.

More:

Acquiring and Applying a License Number

Activating your License

Manual Activation


Acquiring and Applying a License Number

After downloading and installing the AppLife Update software, the software will operate fully featured for a period of 30 days. After 30 days you will need to license the software in order to build an update. By licensing Make Update, the AppLife Update command line utility is also licensed.

To purchase a license, go to http://www.kineticjump.com/buy.aspx

After purchasing a license, you will be emailed the purchased quantity of license numbers.

To apply a license number, launch Make Update. From the Help menu, select the License option.

Copy the license number from the email and paste it into the License textbox.

Once your license number has been applied, full build and publish features will be restored. Your license is applied per user. Logging in as a different user will require applying a different license.


Activating your License

Your license must be activated within seven days of being applied in order to prevent interrupting your ability to use the software. If your system is connected to the internet, simply press the Activate Now button presented when you apply your license.

Note: AppLife Update attempts to automatically detect your network proxy settings. If your network requires manually configuring proxy server settings, you may do so under the Tools..Options..Publishing menu.


Manual Activation

If your system cannot be connected to the internet for activation, you may activate your license manually by using a computer that is connected to the internet or by calling Kinetic Jump tech support during business hours.

To activate manually, select the Tools..Activate menu option. Attempt a network activation. When this attempt is unsuccessful, a manual activation dialog is presented. Note your Machine Name and software version number. On a system that can access the internet, navigate to the manual activation URL (http://www.kineticjump.com/productactivation/activate.aspx). Enter your license number, Machine name, and version number into the web form. Save the file downloaded from the activation server and transfer it to the client being activated. Click on the Activation file… button and browse to the transferred activation file.

You will only need to activate your software once.


Using AppLife Server

AppLife Server is an intelligent platform to host and distribute application updates created by AppLife Update. Compared to using a standard http server for hosting AppLife updates, AppLife Server provides performance improvements, superior access control features, significant analytical information on the status of application deployed clients, and supports the features of the AppLife Manager client application.

More:

Dashboard

Applications

Access Control

AppLife Manager Features

Administration


Dashboard

The AppLife Server dashboard is displayed upon logon to the AppLife Server and allows for a quick overview of all the applications for which the logged on user is involved with, based on their assigned roles.

From their dashboard, uses can link to the Application View for any of their applications by clicking on the View icon [image]. Drilling into an individual Application View provides a look into the published versions for that application, as well as access to deployed client information for that application.

From the Application View, users can click to view/edit individual updates by clicking on the view icon [image] next to the individual Version.

All of the metadata about an individual update can be viewed and modified from the Version view. In addition, access control to the individual update can be viewed and modified.

Back on the Application View, all the individual client installations that are being maintained can be viewed, searched and sorted. An individual client installation can be further investigated by clicking on the information icon [image].

From the Client View, information about each individual update that the client has installed is available. The current client version is easily identified, as well as the results of all their previously applied updates. Executed updates can also be searched.


Applications

Applications are listed on the main page of the AppLife Server user dashboard. The application’s current version and number of active clients are prominently displayed in the dashboard. A publisher can access the details of an application by clicking on the Edit icon within the dashboard.

When editing an application, a publisher can modify:

· Application Name

· Inform Owner of Failed Updated

· Enable AppLife Manager Integration

· Client Access

· Manager Settings

Note that an Application ID cannot be changed. Application ID can only be modified when creating a new Application.

More:

Versions

Clients


Versions

An application contains a list of Versions. This list will include all published updates for an application. It will also include an entry for any client version that has checked for updates, regardless of whether an update exists for that version. For application versions for which an update doesn’t exist, the Release Date is listed as Unknown.

More:

Analytics

Editing Metadata

Removing Versions

Access Control

Publishing with Access Control Lists


Analytics

For any published update version, AppLife Server will identify the total number of Active Client that are running that version, the percent of active clients, the total number of times the update has been applied, the date/time of the first and last time the update was applied.


Editing Metadata

When an update is published, the following information is provided:

· Version Access Mode

o  Access Control Lists allowed

· Test Update Mode

· Targeted previous versions that can apply this update

· Update Summary Text

· Elevation Type

· Allow Chaining setting

· Custom Data string

All of these settings can be modified through the AppLife Server dashboard. Click the View Version Icon to drill into the version details.


Removing Versions

Through the AppLife Server dashboard, a published update can be taken offline by changing the Update Access Mode to NONE. Changing this setting will prevent any deployed clients from discovering and downloading the update, effectively removing the update.

Note: At this time, a published update can only be removed through the AppLife Make Update application (Manage Published Updates).


Access Control

Access can be controlled to individual updates. The default value for Version access control is to use the access control settings of the application. It is often desirable to limit the access to an individual update package. This can be accomplished by setting the Update Access Mode of a designated version to Version. When set to Version, only clients in the selected Access Control Lists will be able to discover and download the designated update version.


Publishing with Access Control Lists

When publishing updates through AppLife Make Update, version specific Access Control can be designated during the publish process.

Note that valid server credentials must first be entered before the list of Access Control Lists is retrieved and made available to select from.


Clients

When deployed installations check the AppLife Server for updates, the server records and tracks their activity. This information is displayed as a Client. Clients are listed on the individual application dashboard view.

The AppLife Update Controller generates a unique Client ID based on the Hard Disk serial number and the complete path location of the main executable of the application. In addition, the Update Controller has a Client Access Key property that can be assigned as an identifier of the individual installation.

In addition to the unique identifiers, the Computer Name, current version and time stamp are recorded as clients check for updates. This information is displayed in the list of Clients.

Clicking on the Information button [image] drills into further details of the deployed Client. From the details view, a list of update history for the client is displayed.

More:

Failure Notification

Search / Sort / Filter

Deleting Client Information

Ignoring Clients


Failure Notification

The designated owner of an application can optionally be informed when a client reports a failed update. An email is sent when a client update fails. This feature is enabled by default. To Enable/Disable, navigate to the application properties from the Application view.

From the Application properties page, check or uncheck the Inform Owner of Failed Updates and click the Apply button.


Search / Sort / Filter

The list of Clients can be sorted by clicking on the column headers within the Clients table.

Clients can also be searched/filtered using the Search textbox above the Client table. The columns that are searched are Client ID, Client Access Key, Computer Name and Version.

Searches are commonly used to filter all clients on a specific version and to find the history of a specific client, based on Client Access Key or Client ID.

Clients filtered by version number


Deleting Client Information

A Client history can be deleted from the AppLife Server by clicking on the Delete icon [image] and confirming the delete.

NOTE: Delete actions cannot be undone.

History of a specific applied update can also be deleted.


Ignoring Clients

Designated Client installations can be selected to be ignored. When a client is ignored, the AppLife Server will still serve updates to the client, but analytical tracking is not performed. Development and testing installations are often elected to be ignored.

To ignore a client, click on the Log icon within the Client View.

Ignored clients are annotated in the Client table.


Access Control

AppLife Server provides access control to applications and updates based on string token identification. The client is identified through either the auto-generated Client ID or the integrator designated Client Access Key. Access Control Lists can be created that include a list of values that identify clients by either Client ID or Client Access Key. These lists can then be assigned to individual applications and update versions.

More:

Client ID

Client Access Key

Access Control Lists


Client ID

The Client ID value is auto-generated by the Update Controller, based on the PC hardware and the complete path location of the hosting executable. The Client ID value can be viewed by:

· Inspecting the ClientID property of the AppLife Update Controller embedded in the host application

· Viewing the Client Details page of the AppLife Server Dashboard

Note: The ClientID algorithm changed in version 1.3.0.0 due to the potential of duplicity in environments where HDD replication is in use for system setups. If you are using Client IDs in Access Lists and prefer to continue using Legacy Client IDs, add the following to your server Application Configuration.

                          <appSettings>

                                  <add key="UseLegacyClientId" value="true"/>

                          </appSettings>


Client Access Key

The Client Access Key is defined by setting the ClientAccessKey property of the AppLife Update Controller within your application source code. The value is often set based on a client license key value or another organizational value of significance.

When using the AppLife Manager, the Client Access Key is set when the client registers a new AppLife Server.


Access Control Lists

The Access Control List editor can be accessed from either the Application Access Control tab or the Version Access Control tab.

Access Lists are scoped to individual applications, however access lists can be configured to be Shared between applications.

To create a new Access List, click the New button on the Access List Editor and provide a name for the list. List names must be unique.

Once created, the list can be selected in the editor, where List Entries will be displayed.

List Entries

A list entry matches a Client ID or Client Access Key value. The list entries are case insensitive.

To add an entry to an Access List, select the Access List and then enter a value to add in the upper textbox.

Access Lists can be added, edited and deleted from the editor view.

List Entries can be added and removed.

More:

Assigning to Applications/Versions

Shared Lists


Assigning to Applications/Versions

Once Access Lists have been created, they can then be assigned to an Application or a Version to control visibility of the applications and updates.

From the Application Edit view, ensure that Anonymous access is disabled. Disabling anonymous access will allow individual Access Control Lists to be checked and unchecked.

Individual Updates can be set to:

· Application Level Access Control – Access to the update is based on the Application Level settings

· Version Level Access Control – Access is based only on the Access Lists specifically checked for the Version.

· None – No access to the specific version is allowed.

Update access control can be set through the AppLife Server dashboard and can be set during an update publish process.


Shared Lists

Access Control Lists are scoped to individual applications, but can be shared between applications.

To share Access Control lists between applications, two actions must be taken.

1. The Access List must be designated as Shared.

2. The application that will consume a shared access list must be configured to use shared lists.

Sharing an Access List

To share an Access List, navigate to the Access List Editor and edit the chosen access list, then check the Share this list option. The user performing this action must be an administrator or a publisher for the designated application.

Consuming a Shared Access List

To consume an Access List shared by another application, edit the properties of application and select the Show Shared Lists option.

Once selected, any lists shared by other applications on the server will be displayed and annotated as Shared. Shared lists can then be selected to be included for access control to the application or version.

For AppLife Cloud subscriptions, Shared Lists are only shared across applications under a single subscription.

Note: When Shared Lists are used, they will be also be displayed in the Access List editor IF the currently logged in user has publisher rights for the application that owns the list. If the current user is not a publisher for the application that owns the shared lists they can select the list but cannot edit the list contents.


AppLife Manager Features

AppLife Server ships with AppLife Manager, a Windows Service and Interactive System Tray interface that supports maintaining Windows applications with absolutely no AppLife Update integration required into the application source code. To use AppLife Manager, simply create an application and configure a new update project.

More:

Installing AppLife Manager

Enabling AppLife Manager


Installing AppLife Manager

AppLife Manager can be installed from any AppLife Server by downloading the Windows Installer (MSI).

http://yourserver/GetAppLifeManager


Enabling AppLife Manager

AppLife Manager is enabled per application by setting the Enable AppLife Manager Integration option within the application settings.


Administration

More:

Users

Applications

Server Settings

Updating your Server

Server Requirements


Users

An AppLife Server user account provides individualized access to the AppLife Server dashboard. When a user logs into AppLife Server, the applications for which they are associated with are displayed on their dashboard.

Administrative users can create and edit new User accounts. To edit users, navigate to the Users view.

Users are identified by a Username. Usernames must be a minimum of six characters in length and must be unique. When creating a new user, a valid email address must be provided. When a user is created, an email is immediately sent to the users email address and this email contains a temporary auto-generated password. Upon first logon, the user will be required to create a new password.

Once the user sets a password, the password is hashed and salted before being stored. It can never be sent in an email or displayed on a page. If the user forgets their password, they can request a new password be generated. When a new password is requested, an email is first sent to the user, who must confirm this action. Only after confirming that a new password was requested will the server generate and send a new temporary password to the user via email.

More:

Roles


Roles

Each user can be assigned Viewer and/or Publisher roles to each individual application. Roles are assigned by editing a User and Selecting the Roles tab or by editing an Application and selecting the Roles tab. A user must be an administrator to manage user roles.

Viewer Role – Allows the application to be displayed on the user’s dashboard. They can interact and view the analytical information provided for the application, its Versions and Clients.

Publisher Role – Allows a user to publish updates and modify Application settings and access lists.

In addition to the Application-specific roles, there are User-Specific roles as well. A user can be assigned:

Administrator – Administrators can create and manage Applications and Users. They can also check for and apply updates to the server.

Global Viewer – When a user is designated a Global Viewer, they can view all server applications.

Global Publisher – When a user is designated a Global Publisher, they can publish updates for all server applications.


Applications

Administrators can Add/Edit applications through the Application view.

More:

Creating New Applications


Creating New Applications

Administrators can create a new application. When creating a new application, the Application ID can be set. Once created, the Application ID can never be changed.

When creating a new application, set the application Owner.

Upon creation of a new Application, the server will send an email to the designated owner that includes all of the relevant information for accessing and using the new Application.

Deleting Applications

When deleting applications be aware that all update packages are deleted with the application. This action cannot be undone. Consider transferring all published updates using the AppLife Update Manage Published Updates feature before deleting an application.


Server Settings

AppLife Server settings are modified through the Config view, which is accessed by administrators from the upper right dashboard menu.

Public URL – Set to the URL that is used to access the instance of AppLife Server

License Key – Enter your server license key

Require SSL – Check to require SSL when accessing the dashboard

Require Controller SSL – Check to require the clients to use SSL when accessing this AppLife Server

Help Phone Number – Set to the number an AppLife Server user would use to request help.

Help Email Address – Set to the email address an AppLife Server user would use to request help.

Smtp Server URL – The SMTP server this AppLife Server will use to send email.

Smtp From Address – The SMTP email address used to send email.

Smtp User – The user credentials used to logon to the designated SMTP server

Smtp Password – The user credentials used to logon to the designated SMTP server.

Setting the SQL database connection string

The SQL connection string is set in the application web.config file.


Updating your Server

AppLife Server can be updated manually or updated automatically.

Manual Updates

As new versions of AppLife Server are published, a manual process package is posted to our website. These manual update packages contains instructions and assemblies. Each update is designed to update a specific target version. You must verify that your currently installed version matches the expected version of the manual update package that you are installing. To verify the current version, log into AppLife Server as an administrator and navigate to the Updates page.

Automatic Updates

If the hosting server is connected to the internet and you can install a maintenance application on the server, updates can be applied by an administrator through the Updates view.

To apply updates for AppLife Server, install the AppLifeServerUpdateService.msi that is included with the AppLife Server installation files.

When an update is available, click the Download button to retrieve the update. When the download completes, click the Install button. When the update completes the page will display a refresh button.


Server Requirements

AppLife Server Requirements:

Microsoft IIS 7.0 or higher

Microsoft SQL Server (Any 2002 or higher)

.Net Framework 4.5 or higher


Using AppLife Manager

AppLife Manager is a Windows Service and Interactive System Tray interface that supports maintaining Windows applications with absolutely no AppLife Update integration required into the application source code.

AppLife Manager ships with and requires AppLife Server.

Software publishers can deploy applications and updates through AppLife Manager that can be completely automatic or can be manual initiated by an end-user through the AppLife Manager UI.

Once installed, AppLife Manager can be configured to check one or more AppLife Servers for Applications to maintain.

More:

Configuring an Application for AppLife Manager

Installing AppLife Manager

The AppLife Manager UI


Configuring an Application for AppLife Manager

Applications maintained by AppLife Manager are configured through the AppLife Server dashboard.

More:

Configuration Options

Automatic Update during Off-Peak Hours

Integrating Application Shutdown

Determining the Currently Installed Version

Client Access Control

Configuration Through AppLife Server

Configuring Through the Make Update New Project Wizard


Configuration Options

There are many options for deploying and maintaining applications with AppLife Manager.

More:

Application Directory

Common Expansion Variables Used

Process Name

Primary Executable

Enable AppLife Manager

Apply Updates Automatically

Update Recheck Frequency (Minutes)

Client Version Identification

Allow Anonymous Access

Integrated API

Public Key


Application Directory

This configuration property defines where the application will be deployed on the client. Windows Environment Variables can be used in the path. In addition to environment variables, the current application ID can be used as well.

Passive Value - *

Setting Application Directory to “*” will leave the application directory unchanged by the AppLife Server. The value can be alternatively set by using the Set Application Directory update action. This action allows an initial update to search a deployed client for an application that is already installed, and then set the configuration based on the existing install folder.


Common Expansion Variables Used

%ApplicationId% - Expands the string value of the current application id guid.

Windows Environment Variables

%ProgramFiles%

%ProgramFiles(x86)%

%CommonProgramFiles%

%CommonProgramFiles(x86)%

%LOCALAPPDATA%

%APPDATA%

%ALLUSERSPROFILE%

%PUBLIC%


Process Name

Enter the name of the application process. This is the process that will be stopped before an update is applied. If the process is running (under any Windows User) while an update is launched, users running the process will be prompted to stop the program by the AppLife Manager UI. The user will have an opportunity to cancel the update process. If the update is cancelled, the application update process is not stopped and no processes will be stopped.

If a user response is not provided within five minutes, the update will proceed and the application process(s) will be stopped.

If the process is stopped by the update, it will be restarted under any user it was previously running under after the update completes.

Note: Application shutdown can be tightly integrated using the AppLife Update API. See Integrating Application Shutdown for more information.


Primary Executable

Enter the file name of the primary executable, relative to the configured Application Directory. (e.g myapp.exe, subfolder\myapp.exe, ..\sibling folder\myapp.exe)

The configured primary executable can be launched by the AppLife Manager UI.

The configured primary executable can also be used to determine the current installed version.


Enable AppLife Manager

This value determines if the AppLife Manager can discover the application. When unchecked, AppLife Managers will not discover the application. If the value was once true and now false, AppLife Managers that previously maintained the application will remove the application and no longer maintain the application on the deployed client. The application is not uninstalled, just no longer maintained and not viewable within the AppLife Manager user interface.


Apply Updates Automatically

When checked, updates will be automatically applied on the deployed clients. No user interaction will be required. If the application is currently running, the user will be prompted before the update is applied. If the application is shut down as part of the update process, the application will be restarted under all users that were previously running the application.

Note: A time window can be configured , allowing updates only during certain times of day.

Note: For applications that are not configured to apply updates automatically, individual updates can be configured to be automatically applied by setting a Custom Data property on the individual update to include Force=true;.


Update Recheck Frequency (Minutes)

Sets the number of minutes between update checks. Value must be greater than 5. The default is 1440 (24 hours).


Client Version Identification

Sets the method of determining the Currently Installed Version.


Allow Anonymous Access

When checked, allows any client running AppLife Manager and configured to check this server to discover the application. When unchecked, only AppLife Manager clients with a Client ID or Client Access Key that exists in a checked Access Control List will discover the application.


Integrated API

When checked, the AppLife Manager will not stop the hosted process directly. It is expected that the application being maintained has a configured AppLife Update Controller and the inter-process communications built into the Update Controller will signal the application to shut down. This inter-process communication also allows for listening for an UpdateStarting event within your application source code. See Integrating Application Shutdown for more information.


Public Key

Sets the public key value of the application. This value is the public portion of the private/public key pair of the AppLife Update project file used to create updates for the application. This value is transferred automatically when the New Project wizard is used to create the AppLife Update project for this application.

Note: If this value is changed after initial creation of the update project, none of the existing update packages previously created with a previous key pair will be valid and will need be removed from the server. This value should only be changed in the event of a compromised private key.


Automatic Update during Off-Peak Hours

AppLife Manager can be configured to update an application during a specific time window only. To configure this option, check the Control Time Window for Updates option and set:

More:

Time to Allow Updates (HH:MM)

Duration to Allow (Hours)


Time to Allow Updates (HH:MM)

Set this value to the time of day with which updates should be allowed to be applied. This value is based on a 24 hour clock. For instance, if you want updates to be allowed starting at 2:00 am, set this value to 02:00. If you want updates to start at 8 PM, set this value to 20:00.


Duration to Allow (Hours)

Set this value to the number of hours that updates will be authorized to be applied after the time to allow. Valid values are from 1 to 23


Integrating Application Shutdown

Using AppLife Manager, no direct integration into your application source code is required for maintaining the application. By integrating an AppLife Update controller into your application, you can ensure any shutdown code is properly executed by instantiating an instance of the Update Controller and listening for the UpdateStarting event. This option is only available for applications created in Microsoft .Net

To integrate, reference the Kjs.AppLife.Update.Controller.dll into your application. This assembly is located in the AppLife Update Install Directory\Public Assemblies folder. This assembly can be freely distributed with your applications.

Once referenced, instantiate an instance of the UpdateController class and set the ApplicationId property to match your application. The Update Controller instance must be scoped to stay instantiated during the life of the application.

The Integrated API configuration property must also be checked. Once you have an Update Controller integrated and the AppLife Manager configuration set, the Update Controller will shut down your application as an update is started and you can interact with the process by listening to the UpdateStarting event.

Note: Your application can cancel the update by setting the UpdateStarting event argument response. See the AppLife Update Controller API Documentation for more information.


Determining the Currently Installed Version

Determining the correct version installed on a deployed client is important in identifying the updates that are available for the application. Using AppLife Manager, there are four methods of determining the current version.

1. AppLife Manager Configuration

2. Primary Executable Assembly Version

3. Primary Executable File Version

4. MSI Display Version

More:

AppLife Manager Configuration

Primary Executable Assembly Version

Primary Executable File Version

MSI Display Version


AppLife Manager Configuration

This is the default method. A version stamp is recorded, along with the rest of the application configuration information that determines application behavior within AppLife Manager. The version stamp is read from the configuration information upon the initiation of an update check, and as an update is executed, the version stamp is written using the Set Update Version update action.

This option is appropriate when your application is deployed and maintained exclusively using AppLife Manager.

When AppLife Manager first discovers an application using this version method, the local version stamp will be 0.0.0.0. The first update published should target this version and perform actions necessary to install the application for the first time, or search the local system for any existing installation and extract the correct version stamp. If an application is found to already exist, the correct existing version number can be recorded in the AppLife Manager configuration using the Set Update Version action.


Primary Executable Assembly Version

For .Net applications that define the installed version through the management of their primary executable .Net Assembly Version, this version can be used by AppLife Manager. Using this option provides improved accuracy for AppLife Manager, as it uses the authoritative source for determining the correct installed version.

When using this versioning style, identifying the correct Application Path is critical in identifying the installed version. For applications initially deployed with AppLife Manager, your Application Path along with the configured Primary Executable, will be identified in the first update.

If AppLife Manager will be used to start maintaining an application that has previously been deployed through other means, the usual configuration is to use the “*” option for Application Directory, and then find the correct installation directory through Update Actions and set the directory value during the first update that targets 0.0.0.0. The Application Directory can be set using the Set Application Directory action.


Primary Executable File Version

For Windows applications that define the installed version through management of their primary executable file version, this version can be used by AppLife Manager. Using this option provides improved accuracy for AppLife Manager, as it uses the authoritative source for determining the correct installed version.

When using this versioning style, identifying the correct Application Path is critical in identifying the installed version. For applications initially deployed with AppLife Manager, your Application Path along with the configured Primary Executable, will be identified in the first update.

If AppLife Manager will be used to start maintaining an application that has previously been deployed through other means, the usual configuration is to use the “*” option for Application Directory, and then find the correct installation directory through Update Actions and set the directory value during the first update that targets 0.0.0.0. The Application Directory can be set using the Set Application Directory action.


MSI Display Version

For applications that use the Windows Installer (msi) exclusively for application maintenance, the MSI Display Version can be used by AppLife Manager for correct version identification.

NOTE: AppLife Update can maintain applications using the Windows Installer through the use of the Execute MSI update action.

All major MSI creation tools will maintain uninstall information on the client, including Display Name and Display Version, which provides a method of version identification that is more straightforward than using MSI Product Code or Upgrade Code values.

To use the MSI Display Version for version identification, you will set the MSI Display Name of your application within the AppLife Manager configuration. AppLife Manager will search the Windows Installer uninstall information for your display name and read the corresponding Display Version for identifying the correct installed version.


Client Access Control

AppLife Manager uses the AppLife Server Passcode Style access management system, where each installed instance of AppLife Manager can optionally be assigned a Client Access Key. The Client Access Key is assigned during the server configuration, and can be edited through Server Configuration.

When an AppLife Manager client initiates server communications, the configured Client Access Key is submitted and compared with the Client Access Lists enabled for server applications that have enabled AppLife Manager Integration. This comparison ignores case. If a matching entry is found for an application, the server will allow access to that application to the client.

More:

Using Client ID


Using Client ID

Each deployed application installation has a Client ID. The Client ID is derived from the physical hardware and the application installation directory. The installation directory is used because AppLife Server supports maintaining multiple independent installations on a single PC.

AppLife Manager maintained applications can use the Client ID for allowing access to individual updates. Client ID should not be used for root level application access unless the Application Path is not maintained by AppLife Manager (e.g. setting the value to ‘*’).


Configuration Through AppLife Server

Applications can be configured through the AppLife Server Dashboard. To manage application settings, click the View Application icon from the dashboard.

Once on the Application View, click on the Edit Icon.

The Enable AppLife Manager Integration configuration option is on the Info tab. All other settings are on the Manager Settings tab.


Configuring Through the Make Update New Project Wizard

New applications created on an AppLife Server that has not yet been configured for AppLife Manager discovery can be initially configured through the New Project wizard within AppLife Update.

When creating a new AppLife Update project, select the AppLife Manager Maintained Application option. Enter your AppLife Server URL and credentials and click the Login button.

Once logged in, any applications for which the supplied credentials are a publisher, but the application has not yet been configured will be displayed.

Select the Application you would like to configure and proceed through the wizard.

Once the wizard is completed, your AppLife Update .aup project file will be created and the corresponding AppLife Manager application configuration will be completed.


Installing AppLife Manager

AppLife Manager can be installed on any Windows client that has the .Net Framework 4.5 or higher installed.

To install AppLife Manager, download the Windows Installer package (msi) from your AppLife Server (http://yourserver/GetAppLIfeManager). Administrative privileges will be required for initial installation.

For AppLife Cloud subscribers, download AppLife Manager from:

https://www.applifeupdate.com/GetAppLifeManager

For AppLife Manager Demonstrations, download AppLife Manager from:

http://demo.applifeupdate.com/GetAppLifeManager

Launch the MSI and follow the installation instructions. Once installed, you will see a system tray icon.

The AppLife Manager is a Windows Service what will run even with no users logged onto the system.

The system tray icon provides a User Interface for the service to interact with any logged in users. When updates are discovered or applied, a balloon will inform the user. The extended user interface can be launched by double-clicking the System Tray icon, or by using the AppLife Manager UI shortcut that was placed in the Windows Start Menu.


The AppLife Manager UI

The AppLife Manager UI lets you interact with the AppLife Manager Windows Service.

More:

Commands


Commands

More:

Add AppLife Server

Manual Check for Updates

Toggle the AppLife Manager UI Output Window

Find your Cloud Subscription Id


Add AppLife Server

Use this command to add a new AppLife Server that the AppLife Manager will check for applications and updates. Adding a new server only needs to be performed once and requires administrative privileges.

1. Click on the Add New Server button.

2. Acknowledge the UAC prompt to elevate permissions.

3. On the Register New AppLife Server window, click the Add button

4. Provide the Server Url of your AppLife Server

5. Provide the Client Access Key that this client will be identified by. This is usually a license key or some other type of individual identifier. If you are going to allow anonymous access to your application(s), this value can be left blank. The Client Access Key can be used to identify the installation within the AppLife Server dashboard. It is recommended that a Client Access Key always be assigned.

6. Provide your Cloud Subscription ID (if using the AppLife Cloud).

7. Click the OK button

Once configured for a server, the AppLife Manager will initiate a server inquiry and begin to manage applications on that server for which the provided Client Access Key has permissions to manage.


Manual Check for Updates

The AppLife Server Windows Service will check for updates for managed applications as configured for each individual application and check the configured servers for changes to any managed applications every 4 hours or as defined by configuration. To manually initiate an update check on-demand, use the Check for Updates button.

This command will initiate an application list refresh and then check all configured applications for updates.


Toggle the AppLife Manager UI Output Window

To view the AppLife Manager UI output window, depress the O button while simultaneously depressing the Control button (Ctl – O).

Information and commands processed by the AppLife Manager can be viewed in the output window.


Find your Cloud Subscription Id

For AppLife Cloud subscribers, your cloud subscription Id can be located in your original subscription email and through the AppLife Cloud dashboard.

Log into the AppLife Cloud. On the top banner, click the Subscription link.

The Cloud Subscription Id can be located in the listed Subscription Information.


Updating Your Software

More:

Updating User Experience Options

Visual Control Configuration Options

Getting Updates

Automatic Update Chaining

Localized Update Process

Executing Updates


Updating User Experience Options

The AppLife Update solution provides a choice of options for integrating an updating user experience into your applications. Using the visual controls included with AppLife Update, you can very quickly integrate a complete updating user experience into your applications. Many customizations are available through the properties of the controls.

You can also build your own updating user experience by utilizing the AppLife Update API. See the Custom Forms Quick Start for more information on building a customized user experience.

Windows Forms Visual Controls

More:

UpdateDisplay Control

UpdateNotifyIconDisplay Control

UpdateDetailsDisplay Control

StatusStripUpdateDisplay Control

Update Interactive

UpdateDisplay WPF Control

UpdateDetailsDisplay WPF Control


UpdateDisplay Control

The UpdateDisplay control is designed to be placed on an application’s main interface, and upon startup, perform a background update check. If an update is present, a download is automatically initiated, with download progress indication. When the download completes, the control notifies the user that an update is ready to be applied.

This control utilizes minimal screen space, displaying a single 16 X 16 icon and a text label. The image and label is configurable by the DisplayMode property. Additionally, the image and text displayed when an update check completes, either with an update available or without, is customizable by setting control properties. Detailed information about the update is available as a pop up, through the control context menu or control click action.

Checking for an update. (Animated image)

Downloading an update. (Animated with progress)

Ready to apply an update. (Customizable text and image)

No updates available (Customizable Text and image)

Update details popup.


UpdateNotifyIconDisplay Control

The UpdateNotifyIconDisplay provides an updating experience through the windows system tray. No visual elements are present on the hosting form. This control can be used independently or simultaneously with other update display controls.

Checking for updates. (Animated image)

Downloading an update. (Animated with progress)

Ready to apply an update (Customizable text and icon).

By default, no image is displayed in the system tray when no updates are available. This can be enabled and customized through the control properties.


UpdateDetailsDisplay Control

The update details display control is designed to provide a drop in details panel onto an existing form.

Checking for an update. (Animated image)

Downloading an update.

Update is ready (customizable image and text).

No updates are available (customizable image and text).


StatusStripUpdateDisplay Control

The StatusStripUpdateDisplay control provides an update experience that resides within a Windows Forms StatusStrip.

Note: This control does is not located in the Visual Studio toolbox. You can add it to an existing Status Strip using the Status Strip Control pane drop-down.

Checking for updates. (Animated image)

Downloading an update. (Animated progress)

No updates available (customizable image and text).

Update is available (Customizable image and text).

With details pop up open.


Update Interactive

The update interactive user experience provides a dialog based updating experience. The update interactive user experience is launched by calling the UpdateInteractive method of the update controller.


UpdateDisplay WPF Control

The UpdateDisplay WPF control is a true WPF control that provides a user experience identical to the WinForms UpdateDisplay control. Being a WPF control, in addition to the property-based customizations available, the control can be re-templated to provide a customized look and feel. The control template can be copied from the AppLife Update installation directory (InstallDir/themes/generic.xaml).

The UpdateDisplay control is designed to be placed on an application’s main interface, and upon startup, perform a background update check. If an update is present, a download is automatically initiated, with download progress indication. When the download completes, the control notifies the user that an update is ready to be applied.

This control utilizes minimal screen space, displaying a single 16 X 16 icon and a text label. The image and label is configurable by the DisplayMode property. Additionally, the image and text displayed when an update check completes, either with an update available or without, is customizable by setting control properties. Detailed information about the update is available as a pop up, through the control context menu or control click action.

The WPF UpdateDiaplay control can be found in the Visual Studio WPF toolbox.

Checking for an update. (Animated image)

Downloading an update. (Animated with progress)

An update is ready (customizable image and text).

No update is available (customizable image and text).


UpdateDetailsDisplay WPF Control

The update details display control is designed to provide a drop in details panel onto an existing form.

Checking for updates.

Downloading an update.

An update is ready (customizable image and text).

No updates available (customizable image and text).


Visual Control Configuration Options

Auto Start

When auto start is enabled, the control will initiate an update process automatically. By setting the AutoStart property to false, the control will not initiate an update check automatically. When disabled, clicking on the control will initiate an update check, and the StartUpdateCheck method can also be used to programmatically initiate an update check.

Auto Hide (UpdateDisplay)

When the Auto Hide option is enabled, the control will perform the update check and download. When completed, if the user does not interact with the control, its visibility will fade to invisible after the designated period of time (in seconds). To enable, set the AutoHideDelaySeconds property to a non-zero value. The default value is 0.

Recheck Delay

The control can be configured to repeat an update check after a period of time by setting the RecheckDelayMinutes to a non-zero value. The default value is 0. For rechecks to occur, the control must also be configured to Auto Start.

Click Action (UpdateDisplay)

The Click Action option determines the behavior when a user clicks on the control. The options are:

· Update (default) – When the control is clicked and an update is ready to be applied, the update process is initiated.

· Show Details Form – When the control is clicked, the update details pop up is opened.

· None – Clicking on the control performs no action.

Display Mode

The control display mode determines the image and text display of an Update Display control. The options are:

· Image and Long Text (Default)

· Image and Short Text

· Image Only

· Long Text Only

· Short Text Only

When long text is selected, the status of the control shows a more verbose label than when short text is selected.

Application Name

When the application name property is set, it is displayed on the update details, system tray bubble, and tooltips.

No Update Text and Image

When the No Update Text and Image properties are set, these customizations replace the default image and text that the control uses in this update state.

Ready to Apply Text and Image

When the Ready to Apply Text and Image properties are set, these customizations replace the default image and text that the control uses in this update state.

Apply Update Options

The Apply Update Options property lets you configure the options available as an update is initiated.

UpdateReady Event

The UpdateReady event is raised on the controls when an update download is completed.

Show Close Button (UpdateDetailsDisplay)

A close button can be displayed on the Update Details Display by setting the ShowCloseButton to true. The CloseRequested event is raised when the button is clicked.

CloseRequested Event

The CloseRequested event is raised when the close button shown on the control is clicked.


Getting Updates

The process of retrieving an update from a network resource is controlled by the Update Controller. The Update Controller is a component placed in your application. The Update Controller contains three properties that determine how updates are retrieved.

Update Location

The network URI that identifies where to look for updates. This value can be:

· A file path (C:\My Applications\Updates\App1)

· A UNC Path (\\mynetworkserver\Updates\App1)

· An http location (http://mywebserver/Updates/App1)

· An https location (https://mysecureserver/Updates/App1)

· An ftp location (ftp://myftpserver/Updates/App1)

ApplicationID

Every application has a unique guid identifier. The update controller will not attempt to update from an update location with a different Application ID.

Version

The Version property identifies the version of the software requesting an update. Versions are of the form <Major>.<Minor>.<Build>.<Revision>. When updates are published, they can be made available only for specific previous versions, allowing for a great deal of flexibility in software update package management.

When an update check is performed, the Update Controller looks for updates at the specified Update Location that targets the version of the client. The updates at the location must match the application id of the update controller. If there is an update available, information about the update can be displayed to the user. The update can also be downloaded and applied.

More:

Versioning

Director

Check for Update

Intervening during a Check for Updates

Custom Data

Downloading

Download Authentication

Download Verification

Proxy Servers


Versioning

In order to determine the availability of an update, the current software version must be known. AppLife Update supports two mechanisms for determining the current software version. You can use either the Version property of the Update Controller, or the assembly version of the host executable.

More:

Update Controller Version Property

Host Assembly Version


Update Controller Version Property

If you use the Version property of the update controller, you can set the version property programmatically. This version number does not need to match the assembly number of the host application. This versioning scheme is commonly used to enable updating without being required to re-build the application assembly being updated. It is also used when a sub-component of an application is being updated separately from the main application. The UseHostAssemblyVersion property must be set to false in order to use this versioning technique.


Host Assembly Version

The current client version can be determined by reading the .Net Assembly Version of the host application. This value is set by the .Net framework [assembly: AssemblyVersion] attribute. To use the host assembly version, set the Update Controller UseHostAssemblyVersion property to true. When using the host assembly version, the Update Controller Version property is ignored.

Synchronizing the Update package version with a file

To automatically set the update version while building new updates, you can link the update version of newly created update packages to a file on your build system. When linked, the update version of new updates is automatically assigned to the assembly version or file version of the designated local file.


Director

The Director file is created upon first publishing an update, and maintained as each additional update is published. The file contains information about each update and is used to determine update availability and provide information about the updates. Each update location contains a Director file.


Check for Update

Methods on the Update Controller are used to Check for Update. When checking for an update, the Director file is downloaded and analyzed by the Update Controller to discover any available updates that target the current application version. If there is an update available, the information about that update is presented.


Intervening during a Check for Updates

Through the UpdateFound event of the Update Controller, implementers can intervene when an update is discovered. This might be necessary to check licensing or validate a specific client’s eligibility to receive an update. From within this event handler, an implementer can allow the update, cancel the update, or even choose from a list of the possible earlier updates for the specific target being updated.


Custom Data

For each update, a publisher can set a Custom Data text property. This property is available to you during a Check for Update operation and can be used for special custom processing or decision making. Kinetic Jump does not use this property for any actions and you can freely use it to customize your update discovery process.


Downloading

When an update is found to be available, the update package is downloaded and placed into a temp folder. As the file is being downloaded progress indication is provided to the user. A download can be canceled by the user.

More:

Cached Downloads

Resuming a Failed Download


Cached Downloads

An update package is cached as it is being downloaded. When the download is complete, it is available to be applied. If an update was previously downloaded and cached without being applied, the update can be applied without asking the Update Controller to download the update package again. From the Update Controller’s CurrentUpdate property, an integrator can identify whether the current update is already downloaded by referring to the IsDownloaded property.


Resuming a Failed Download

Downloaded update packages are cached to disk during the download process. If your network connection is lost during an update download, the next download attempt will resume from where the previous download failed. If an update download was completed, but not applied, the update package will be persisted and ready for the next update attempt.

To specify a preferred folder to download update packages, you can set the PreferredDownloadPath property of the Update Controller prior to downloading the update. You must ensure that the designated folder exists and that the user performing the update has permissions to write to the preferred directory.


Download Authentication

Server credentials can be set on the AppLife Update Controller that allows the controller to download updates from server locations that do not allow anonymous access.


Download Verification

Upon successful download of a discovered update, the downloaded file is verified to be intact and that it came from the same publisher that supplied the application being updated. This is accomplished using the RSA Crypto Service Provider Sign Data functionality. When a new Update Project (aup) is created using the Make Update application, an RSA public-private key pair is created. The private key is used to sign the update package after it is built. The public key is placed in the PublicKey property of the Update Controller.

When a new update package is created, the resulting file is signed using the RSA Crypto Provider and the private key of the update project. The signature of the package is placed in the Director file to be provided to the application while downloading an update.

When the hosted application downloads the update package, the signature and public key are used to verify that the downloaded file has not been changed, and that it came from a source that had the proper private key. If any changes were made to the file, or if the update package had been created without the appropriate private key, the verification will fail and the update package is discarded.

Note: This verification process assumes the sanctity of the private key. If a private key is compromised, AppLife Update would not be able ensure the update package file originated with the original software publisher.


Proxy Servers

Many networks today use proxy servers to control internet access. On these networks, a client application looking for the Uri identified by the UpdateLocation property of the Update Controller might have to navigate first to a proxy server. The application must know the network location of the proxy server for this to occur. The AppLife Update Controller supports automatic proxy detection as well as manual proxy settings.

By default, Automatic Proxy detection is enabled. To set manual proxy information, properties must be set on the Update Controller. A user interface to allow a user to interact with these settings, and a persistence mechanism are not provided by AppLife Update. Implementers needing this functionality must provide this within the hosting application.

Update Controller Proxy Properties

AutoDetectProxy (true by default)

Proxy Address

Proxy Domain

ProxyUseDefaultCredentials

ProxyUserName

ProxyPassword

Proxy Domain

BypassProxyOnLocal


Automatic Update Chaining

Updates chains are made when the current version must first apply one or more updates before the highest available update can be applied. This commonly occurs when dated application installers are used to install your application, or when your application is infrequently used.

The default behavior of AppLife Update would result in the intermediate update versions being discovered and applied individually. You can enable automatic chaining. When automatic chaining is enabled, all available updates are downloaded in a single process, and each update is sequentially applied before your application is restarted as the highest available version.

To enable automatic chaining, set the EnableAutoChaining property of the Update Controller in your application to true.

Non-Chainable Updates

If you publish an update that would not participate properly within a chain of updates, you can designate that update as non-chainable. An update that requires the operating system to restart, or that might rely on activity that your application performs as it is restarted are examples of non-chainable updates. To designate an update as non-chainable, clear the Allow chaining from this update checkbox as your update is created. This value can be modified after the update is built by managing published updates.


Localized Update Process

The AppLife Update Controller contains built-in forms that allow an implementer to quickly implement a complete update process. This includes a form to check for updates, a form to download an update, and an error status form. The Update Interactive method of the Update Controller uses these forms. You can also use each of the forms individually.

The built-in update forms are localized to the following cultures:

· English (en-us) – default

· Chinese – Traditional (zh-CHT)

· French (fr)

· German (de)

· Italian (it)

· Japanese (ja)

· Spanish (es)

When AppLife Update enabled applications utilize the built-in user interface forms, the forms are localized for clients with these Windows versions.

Implementers that do not desire these localizations can remove the culture specific folders containing the localized resources from their application directory.

Customers who would like these user interface forms localized to their culture and are willing to perform the string translations can find information about this process at http://www.kineticjump.com/update/localization.aspx


Executing Updates

Updates are discovered, downloaded and verified to be intact and from the original publisher. Only then can an update be executed. To execute an update package, the Update Controller component initiates the process by communicating with all instances of the hosting application and requesting a shutdown. Implementers can handle the UpdateStarted event of the Update Controller to perform any necessary actions prior to shutdown, such as prompting to save work. The update can also be cancelled from that event. Once the instances have been shutdown, the initiating instance extracts and executes an Update Launcher.

The Update Launcher initiates the update process and then waits until the updating executable completes its work. After the update is complete, the hosting application is launched in its updated state.

The executable that actually performs the update is determined by the Make Update project. It can be either a Microsoft Installer file, a custom created executable, or it can be an AppLife Update Action List executable. The best method to use is dependent on the type of application being updated and the preferences of the developers.

More:

Supported .Net Frameworks

Preserving Command Line Arguments

Microsoft Installer Patch

Custom Update Executable

AppLife Update Project

AppLife Update Engine Options

Coordinated Application Shutdown

Passing in Shared Properties for an Update

Implementing a Custom Update Engine User Interface (IUpdateUI)

The First Run after an Update

Accessing the Results of the Previous Update

Localized Update Engine User Interface

Elevated Privileges

Recovering From a Compromised Private Key

The Update Log

Customize the Log Location

Disable Logging

Accessing Logs through the API

64 Bit Operating Systems

Windows Presentation Foundation (WPF)

The User Account Control (UAC)


Supported .Net Frameworks

AppLife Update can successfully update .Net applications that target the .Net Framework 2.0 or higher. AppLife Update fully supports the .Net 4.0 framework.


Preserving Command Line Arguments

When the host application is re-launched after an update is executed, you can choose to include the original command line arguments that were passed to the pre-update session. To do so, set the Update Controller property AutoCopyCommandLine to true. The default value is false.


Microsoft Installer Patch

If your organization uses an install creation program such as InstallShield or Wise, you might already be creating Microsoft Installer major upgrades, minor upgrades and patch files for your software. If this is the case, you can utilize the Execute Msi update action to launch your upgrade or patch during an update. You can define the exact command line parameters to pass into the msiexec.exe. When the package is downloaded, verified and executed, your patch will be automatically executed on the client computer.

Note: Microsoft Install Patches cannot be created directly within a Visual Studio Setup Project. You can create an installer patch using the Microsoft Installer SDK. More information can be found at http://msdn2.microsoft.com/en-us/library/aa372866.aspx


Custom Update Executable

If your organization utilizes a custom executable to update your software, or your application requires very unique procedures in order to be updated, you can utilize AppLife Update to manage and distribute these updates. You can apply your custom patch using a Run Command Line Update Action during an update.

Note: Custom Actions within an AppLife Update action list might be a better alternative to the custom executable.


AppLife Update Project

The AppLife Make Update application can be used to define a list of actions that are to be executed on a client computer in order to update your software from one version to another. Actions such as replacing files, modifying registry keys, and registering COM components can be configured in a sequential manner to update your software. These actions are designed to address the most common update steps required for .Net applications. In addition each action is architected to ensure a complete rollback should any update action fail. This prevents the client software from being placed in a comprised condition. If the built in actions are not sufficient to update your software, you can easily create custom actions using any .Net language. Your actions can then be added the list of actions to be executed when your software is updated.


AppLife Update Engine Options

When using an AppLife Update Action List Project, your updates are executed on client systems by the AppLife Update Engine. The operation of the AppLife Update Engine user is configurable within the host application code.

Configuration options for the AppLife Update Engine user interface include:

No User Interface

You can choose not to show this form at all during an update. This options allows you to silently update your application.

Immediate Close

By default, the AppLife Update Engine user interface shows an “update complete” message and requires the user to click a close button to complete the update. Upon clicking the close button, the newly updated application restarts. You can choose not to require the user to click a close button and have the update user interface immediately close upon completion of applying the update.

No Restart

You can configure the AppLife Update Engine interface to not restart the application upon completion of the update.

No Shutdown

By default, when an update is applied, the application hosting the Update Controller is shutdown so that its assembly can be replaced during the update process. In some implementations, this is not desired. You can configure your update process to not shutdown the hosting application during an update process.

These options can be combined for custom configurations. The ApplyUpdate and the UpdateInteractive methods of the Update Controller provide overrides that allow you to configure these options.


Coordinated Application Shutdown

When an update is applied, inter-process communication takes place between all running processes with an instantiated Update Controller. When an update is executed, an attempt is made to shutdown any process with an Update Controller configured with the same ApplicationID as the initiating controller. In each of these processes, the UpdateStarted event is first raised to allow the implementer to perform any necessary work prior to the shutdown attempt. From this event the implementer can control the behavior of the update process.

1. Inspect the physical path of the instantiating host assembly, and use this information to support independent side-by-side application updating.

2. Cancel the update process currently in progress.

3. Ignore the update process, and prevent the current instance from being shutdown, without canceling the entire update process.

4. Pass from the initiating application instance to all other instances custom data that can be used to determine the proper behavior to take. Set the UpdateController.CustomIpcData property and investigate the UpdateStarted Event Arguments custom data property.

Note: When the application update process is configured for No Shutdown by using the ApplyUpdateOptions.NoShutdown parameter, only the initiating update process will not shutdown. The inter-process communication still occurs and the UpdateStarted event is raised on all other instances. If your implementation should prevent other processes from shutting down, handle the UpdateStarted event and set up your desired behavior.

Disabling IPC

Update Controller Inter-Process Communications can be disabled by setting the Update Controller DisableControllerIPC property to true.


Passing in Shared Properties for an Update

Shared Properties can be defined within the host application and passed into the update process as the update is initiated. This allows you to pass client-specific information into the update process and use this information to control the behaviors of update actions. Shared Properties can be used as part of Update Action conditional expressions as well as within dynamic actions and custom actions. For more information, reference the AppLife Update API documentation from the Help menu.


Implementing a Custom Update Engine User Interface (IUpdateUI)

The user interface that is displayed to the user while an update is being applied can be customized to match the visual appearance of your application. For customers that would like to add more in-depth visual customizations than are possible through the Project Properties options (adorn a logo image and modify the window title), the standard user interface can be completely replaced with your own customized UI by implementing the Kjs.AppLife.Update.Engine.Core.IUpdateUI interface.

(Left Image – Default User Interface, Right Image – Example Customized User Interface)

To replace the Update Engine UI, you will create a new .Net assembly (.dll or .exe), reference the AppLife Update Core assembly and include one class that implements the IUpdateUI interface. This class will be called by the Update Engine, and should display and update the user interface as the interface methods are called by the AppLife Update engine.

The assembly can then be imported into your AppLife Update project, after which all future update packages built by the project will include the new customized user interface.

IUpdateUI Operations

1. As the update engine starts, the IUpdateUI.Open() method is called. In this method you should create and show your customized user interface. Your user interface should remain visible until the IUpdateUI.Finish method is called.

2. As the update progresses, the IUpdateUI.Update() method is repeatedly called. This method has parameters that provide information about the current state and progress of the executing update. This information can be used to provide visual feedback within your customized user interface.

3. When the update is finished, the IUpdateUI.Finish() method is called. This method has parameters that indicate the condition of the update. If an error occurs during the update, error information is provided through the error parameter. The customized user interface can be safely closed anytime after this method is called, but should not be closed before this method call.

4. If the ApplyUpdateOptions.AutoClose option is set by the host application code that initiated the update process, the IUpdateUI.Close() method is called immediately following the Finish method. If this method is called, it is expected that your custom user interface be immediately closed. Note: If you utilize a System.Windows.Forms.Form class and implement the IUpdateUI interface, this method is already present.

5. Some update actions request a Yes/No response from the user. To support this, your customized user interface must implement the IUpdateUI.ShowYesNoPrompt() method.

6. As your customized user interface is closed, the update engine is notified by your class raising the IUpdateUI.Closed event. Note: If you utilize a System.Windows.Forms.Form class and implement the IUpdateUI interface, this event is already present and is raised when the form is closed.

7. Your custom user interface can optionally support canceling an update, as well as pause and resume features by raising the IUpdateUI.RequestCancel, IUpdateUI.RequestPause, or IUpdateUI.RequestResume events.

A sample implementation of a custom update engine user interface is available within the Custom Forms Quick Start example.

For more information on the Kjs.AppLife.Update.Engine.Core.IUpdateUI interface, reference the


The First Run after an Update

You can identify the first time your application restarts after an update has been applied by checking the state of the IsFirstRun property of the Update Controller. This value will be true if this is the first start after an update.

Note: Is First Run is user specific. This value should only be relied upon if the user initiating the update will be the user that first restarts the application.


Accessing the Results of the Previous Update

The results of the last update to be applied can be accessed using the ReadLastUpdateInformation method of the Update Controller. This method returns the following information about the last update to be applied:

· Completed Time
The time that the update completed execution

· Error Text
If the last update ended in an error condition, the text of the error can be read.

· Log Path
The path to the action list log file that was created by the update.

· Result
The final result of the update. Success, Failure, Cancellation.

· Starting Version
The software version that initiated the update

· Update Version
The update version that was applied.


Localized Update Engine User Interface

The AppLife Update engine has been localized for the following cultures:

· English (en-us) – default

· Chinese – Traditional (zh-CHT)

· French (fr)

· German (de)

· Italian (it)

· Japanese (ja)

· Spanish (es)

When creating an update project, you can choose one or more languages to provide your update for. You can also supply culture specific release notes for each language selected.

Customers who would like the AppLife Update Engine localized to their culture and are willing to perform the string translations can find information about this process at http://www.kineticjump.com/update/localization.aspx


Elevated Privileges

Depending on the installed structure of your application, it is sometimes necessary for elevated user privileges to accomplish a software update. For example, a standard user cannot replace a file in the Program Files directory. In these circumstances it is necessary to elevate privileges in order to execute an update.

AppLife Update Windows Service

If you are using an AppLife Update action list to update your software, you can elevate privileges by configuring your software to use the AppLife Update Windows Service. This windows service runs under the context of the local system account.

The AppLife Update Service can ONLY be used with an AppLife Update action list. Msi based updates can utilize the elevation features of the Windows Installer. AppLife Update provides no means to elevate privileges during a custom exe update.

To use the AppLife Update Windows Service:

1. Configure your application by setting the ElevationType property of your Update Controller to AppLifeUpdateService.

2. Add the AppLife Update Windows Service to your application installer. The merge module will install the service and register your application for use. Only registered applications can interact with the service.

When your application distributes the AppLife Update Windows Service and is properly configured to utilize the service, the update engine will execute your update packages under the security context of the Local System. The AppLife Update engine user interface communicates with the service to provide your users progress indication as the service executes your update package.

Applications that utilize the AppLife Update Windows Service will not be prompted by the Windows Vista User Account Control (UAC) when an update is executed.

All of the built-in update actions perform identity impersonation to ensure that any update activity that targets the current user profile will be properly executed by the AppLife Update Windows Service. Custom actions that you create can gain access to the Windows Identity of the user who initiated the update using the Target Application Identity information on the Update Context object. More information on this topic is available in the API Reference.


Recovering From a Compromised Private Key

The security of your application is dependent on keeping your private key private. It is imperative that your application project (aup) file be kept securely private.

In the event that your private key is compromised, your software and your clients are at risk of being maliciously targeted. If you have deployed the AppLife Update Service for elevated permissions, then your client computers are at a higher risk because malicious code could execute with permissions higher than the logged in user.

Attackers could use your private key to create a malicious update package. To execute this compromised update package, attackers would need to place this update package in your application’s publish location. With a malicious update signed with your private key and placed in your update location, your update process will discover, retrieve, validate and apply the malicious update package.

It could also be possible for attackers to bypass your application entirely, if they could successfully trick your users into executing a Trojan executable. The severity of this scenario increases if the AppLife Update Service has been deployed with your application.

If you suspect that your private key has been compromised, your update location must be secured, preventing an attacker from gaining the ability to add or modify files. A new key pair must also be implemented in your application and your clients must be updated as soon as possible with the new public key.

You must update all versions of your software.

1. Create a backup of your current Make Update project file and archive it.

2. Create a new AppLife Make Update project file.

3. Within your software, modify the public key property of your update controller to match the new Make Update project file public key.

4. If necessary, build your software and then create a new update. If you have deployed the AppLife Update Service, include in this update a Replace Public Key action. Place the new public key that matches your update controller.

5. After publishing the update in step 3, import into your project the new key pair from the new Make Update project file and remove the Replace Public Key action from your update project.

6. Set your Versions to update property to >[Previous Version] and save your project file.

7. No future updates can target versions with the previous public key. These updates will fail validation and not be executed.


The Update Log

During an update, a log file is created that documents the actions that are performed. This log file is used to diagnose update execution errors. The log file is located in the current user’s local application data folder.

Windows XP:

C:\Documents and Settings\[user]\Local Settings\Application Data\Kjs.AppLife.Update

Vista:

C:\Users\[user]\AppData\Local\Kjs.AppLife.Update

Elevated Updates

Updates that use the AppLife Update Windows Service are executed by the Local System account. The Local Application Data folder for the Local System Account is located in the profile for the Local System Account. After the update completes, the log file is copied to the initiating users log location.

Windows XP:

C:\Documents and Settings\LocalService\Local Settings\Application Data\Kjs.AppLife.Update

Vista: C:\Windows\System32\config\systemprofile\AppData\Local\Kjs.AppLife.Update


Customize the Log Location

You can define your own logging location for your application by adding the appropriate registry entries described below. With a custom log location defined, your application will always log to the defined folder whether the service is used or not. If your custom logging folder doesn’t exist, AppLife Update will attempt to create it. If the folder can’t be created, or the current user does not have permissions to write there, the log will be written to the default AppLife Update logging location.

Defining your log location:

Add a registry key for your application ID under the HKLM\SOFTWARE\KineticJump\AppLifeUpdate\ApplicationSettings registry key and add a LogDirectory String value that contains the path to your log folder.


Disable Logging

Update execution logging can be disabled for a designated application. To disable logging, add a registry value:

HKLM\SOFTWARE\KineticJump\AppLifeUpdate\ApplicationSettings\ {ApplicationID}

DisableLogging (DWORD)

If this value is present with a value of 1, logging will be disabled for the designated application id.


Accessing Logs through the API

Using the AppLife Update Controller, you can programmatically access update history for your application. Update history includes:

· The initial version number being updated

· The version of the update package

· The start and end time of the update

· The update result

· The type of elevation used

· The log file path

· The summary text

· The custom data

Use this information for troubleshooting update issues and to provide access to update history for your users.

The Update Controller has a static method named GetUpdateHistory that will return a collection of LoggedUpdate classes. Please see AppLife Update API Reference from the help menu for more information.


64 Bit Operating Systems

The Windows XP and Windows Vista operating systems have 64 bit versions. Special consideration must be given when installing and updating software on 64 bit operating systems. These 64 bit operating systems have a 32 bit sub-system for compatibility with 32 bit software. AppLife Update provides update authors the ability to specifically target the 32-bit sub-system registry and file system. Update authors can also explicitly register 32 bit and 64 bit COM assemblies.

Applications built to execute in 64-bit mode will automatically integrate with the 64-bit system, and 32-bit applications will automatically interact with the 32-bit sub-system. Installers are not as straightforward and care must be taken to ensure applications operate as expected when installed on a 64-bit Windows operating system.

With AppLife Update, any action configured to target an x86 sub-system on 64-bit operating systems will also target the equivalent location on 32-bit operating systems.


Windows Presentation Foundation (WPF)

The AppLife Update Controller is completely compatible with the .Net Framework 3.5 and WPF applications. Though the built-in user interface forms that are in the Update Controller are Windows Forms based, they can still be shown from WPF applications. In addition, you can completely customize your user interface using WPF XAML, just as you can create custom winforms user interfaces.

Integration Points to consider with WPF applications

1. The Update Controller is Disposable
The controller class is disposable and must be disposed when you are done using it. Placing a controller on a WinForms designer adds the control to the form container, and the container ensures that the controller is disposed when the form is closed. In WPF this won’t be the case.

If you intend to utilize the built-in Inter-process communications(IPC) of the update controller to coordinate the shutdown of multiple instances, then instantiate your controller and keep it instantiated throughout the lifetime of your main WPF Window. Ensure the control is disposed as the Window closes.

2.  Setting the Owning Form
To
utilize the built-in user interface for updating, the Update Controller methods
expect a IWin32Window class for the owner parameters.  If you
don’t set an owner, the dialogs that the Update Controller displays will not be
properly positioned.  You can easily wrap a WPF Window using this simple
wrapper class, allowing you to pass the WPF Window to the Update Controller
properties.

private class WindowWrapper : System.Windows.Forms.IWin32Window {
private System.Windows.Interop.WindowInteropHelper mHelper;
public WindowWrapper(Window window) {
if(window
!= null)
{
mHelper = new System.Windows.Interop.WindowInteropHelper(window);
}
}

public IntPtr Handle {
get {
if(mHelper
== null) {
return IntPtr.Zero;
} else {
return
mHelper.Handle;
}
}
}
}

Example Usage:
mController.UpdateInteractive(new WindowWrapper(this));


The User Account Control (UAC)

On Windows 7 and Windows Vista, privileged users execute applications with a limited security token. When a privileged user attempts to perform an action that required higher privileges, they are prompted for confirmation ( Limited users are prompted for credentials). If your update package requires higher credentials to complete and have chosen not to deploy and use the AppLife Update Windows Service for elevation, you can utilize the UAC to attempt elevation.

The default behavior of the Update Controller is to initiate an update using the same privileges as the current user. You can set the Update Controller to utilize the UAC or the AppLife Update Windows Service for permissions elevation using the ElevationType property.

If you choose the UAC, the update is launched from an unknown publisher:

You can optionally code sign the launcher for your update project. The launcher is compiled by Make Update and cannot be used with any other project than the one that created it. Code signing the launcher allows you to identify your organization as the publisher of the update that your users will apply.

To code sign your launcher, choose the UAC Launcher menu item from the Tools menu.

1. Using the dialog, you can optionally specify an icon for your launcher, then save the executable file to your file system. Keep track of the saved exe file as it is the only file that can be imported back into the update project.

2. Code sign the saved executable using your organizations certificate. If you do not have a certificate, there are many vendors who can provide this.
www.verisign.com
www.thawte.com

3. Import the code signed executable back into your AppLife Update project file.

Once imported, future updates will properly identify your organization as the publisher of the update.


Building Your Update

More:

Initial Install

Building an Update Package

The AppLife Update Engine

Target Versions

Update Summary Text

Publishing a Test Update

Proxy Settings


Initial Install

There are many ways to deploy your application. The most common method used is an MSI setup program, but just file copying is also a method (XCopy deploy). After your initial install, AppLife Update helps you maintain your deployed installation by providing the means to build and publish updates that your software downloads and applies.


Building an Update Package

The Make Update application is used to build update packages. Using Make Update, an update is created by adding Update Actions to the action list in your AppLife Update project. When you build an update, all of the actions in the action list are processed, and all of the new files and instructions defined in the action list are packaged up into an update package. This is a file names major.minor.build.revision.zip. The update package is compressed with gzip compression, but given the zip extension so that web servers won’t block serving them up.

To create an update, click the Create an Update… button.

1. Set the Update version of the new update.
Note: This value can be automatically set by referencing the assembly version or file version of a designated file. See Project Properties

2. Define the previous versions that can successfully apply the new update.

3. Write any summary text information that you would like the user to see. (This information is available from the Update Controller when the update is discovered).

4. Select one or more update locations to publish the new update to.

5. If your publish location requires credentials, you can enter them here.

6. Click the Build button to build and publish the new update.


The AppLife Update 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.

· Prepare

· Execute

· Cleanup

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.


Target Versions

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.

More:

All Targets

Greater Than or Equal To


All Targets

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.


Greater Than or Equal To

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.


Update Summary Text

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.

More:

No Update Summary Text


No Update Summary Text

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.


Publishing a Test Update

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.


Proxy Settings

AppLife Make Update 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.

Note: Ftp publishing through an http proxy server is not supported. In this scenario, you must use http publishing or bypass your proxy server for ftp.


Managing Published Updates

Project update locations can be managed through AppLife Make Update. To manage an update location, click the Manage Published Updates… button and select the location that you wish to manage.

From the location management dialog, all of 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.

· 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.

· Copy an update to another location
A selected update can be copied to another update location.

· 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.

More:

Publishing Changes

Comparing two Update Locations


Publishing Changes

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.


Comparing two Update Locations

Two update locations can be compared. Comparing update locations lets you see at a glance any missing or different updates between them. To compare two locations, click to Manage Published Updates… then check to compare locations, and select the location that you wish to compare.

The location selected in the list is Location A, and the location in the combo box is Location B.

The comparison dialog shows the updates at the two selected locations, along with adornments indicating information about the updates. In the example above, you can see that location B does not contain an update for version 3.0.0.0. In addition, there is a difference in version 2.0.0.0. Updates can be copied from one location to another using the Copy left and Copy right buttons. In addition, when differences are present in a specific update version, you can see the differences by selecting the update and clicking on the Show differences link.

Copying update 3.0.0.0 right, and update 2.0.0.0 left results in update 3.0.0.0 being published to location B, and the test status being cleared for update 2.0.0.0 in location A. Publishing these changes results in the two update locations becoming identical.


The AppLife Update Windows Service

The AppLife Update Windows Service allows limited users to securely apply updates that you publish under the security context of the local system account. This provides the ability to maintain your application on deployed clients without administrative support.

To use the AppLife Update Windows service for elevation, you must set the ElevationType property of the update controller AppLifeUpdateService. You must also deploy the service with your application and ensure proper registration. Deploying the service and registering your application to use it does require administrative privileges. Once deployed, your updates can be applied by limited users.

More:

Service Registration

Viewing your Project File Public Key

The AppLife Update Service Registration Utility

Deploying the AppLife Update Windows Service


Service Registration

To utilize the AppLife Update Windows Service, your application must be registered with the service. The service will validate any update package that is applied with a public key that resides in the system registry.

Registration adds an entry for your application in the system registry. The service will look for this entry when your application attempts to use it to apply an update. Entries are added to:

HKLM(x86)\SOFTWARE\KineticJump\AppLifeUpdate\ServiceKeys\appkey

Your appkey must include two values:

Path – The complete path to the host executable. This is your application.

Public Key – The public key from the application Make Update project (aup).

An application path should only be registered once. If a single host application applies updates from multiple AppLife Update projects, all projects must share the same key pair. (See importing key pairs ).

To manually register your application, add the necessary registry keys. When the AppLife Update Windows Service is deployed using the merge module included in the AppLife Update application directory, registration is accomplished by setting the two merge module properties.

Applications that attempt to use the AppLife Update service and are not registered will fail with an update package failed validation message.


Viewing your Project File Public Key

Open your AppLife Update (aup) project in AppLife Make Update. Open the project settings dialog from the Project menu. On the security tab, the public key is displayed.


The AppLife Update Service Registration Utility

To register applications with the service during development, you can use the AppLife Update Service Registration utility. This utility can be launched from the Make Update Tools menu, as well as from the WinForms and WPF Update Control designers.

With the service registration utility, you can easily add registrations for applications under development on the development system.

Adding a registration…


Deploying the AppLife Update Windows Service

If you have configured your application to utilize the AppLife Update Windows Service, you will utilize the service merge module for deployment. Using the merge module ensures proper reference counting for uninstalling. The service is a shared resource and a single instance of the service is installed for all AppLife Update enabled applications on the system. The service merge module also registers your application for use with the service.

The AppLife Update Windows Service merge module is located in AppLife AppDir\UpdateService\AppLifeUpdateService.msm.

To use the Update Service merge module, add it to your Windows Installer setup. The merge module has two configuration properties that must be set.

Path
Set this value to the path of the application executable that hosts the Update Controller. You can use windows installer database properties to identify the location of your executable. A common value for this property is [TARGETDIR]yourapp.exe

Public Key
Set this to the public key of your application project. This is the same value as the PublicKeyToken property of the Update Controller. You can also view your project public key from the project settings dialog.

Note: The merge module adds a requirement for administrative permissions to execute your Windows Installer.


Deploying an AppLife Update Enabled Application

Update Controller

To deploy an AppLife Update enabled application, ship the Kjs.AppLife.Update.Controller.dll assembly with your application. The controller assembly should be located in your application directory.

Using Localized Resource (de, es, fr, it, ja, ru, zh-CHT + community translations)

AppLife Update ships with localized resources. The localized satellite assemblies are located in the InstallDir/PublicAssemblies/Localized Resources directory. To include localized controller resources, move the specific locales from this folder into the folder that contains the Kjs.AppLife.Update.Controller.dll.

WPF Controls

If you are using the WPF controls, you must ship the Kjs.AppLife.Update.Wpf.dll assembly along with the update controller assembly.

The AppLife Update Windows Service

If you have configured your application to utilize the AppLife Update Windows Service, you must ship the Windows Service with your application. See deploying the windows service for more information.

The update engine and update actions are not deployed with your application. They are included in every update package. Your application extracts the engine from the downloaded update package as updates are applied.


Update Options

More:

Controlled Rollout

Customized Forms


Controlled Rollout

When a new update is made available to a large audience of clients, the availability of the update can be limited for a specified period of time. By controlling the initial rollout, you can avoid bandwidth and server loading issues that might occur.

A controlled rollout limits the number of clients that can discover the update for a specified time period. This time period is set on the Update Controller ControlledRolloutHours.

When the hosting application is launched, a random number between 0 and the number of controlled hours is generated. This number represents the hour after which a new update was published, that this client can receive the update. Statistically, the clients should be evenly distributed across the designated controlled rollout period.

When the Update Controller checks for an available update, the universal time difference between now and when the update was published is calculated. If the time difference is in the Controlled Rollout window, the randomly generated number is checked to see if it is less than the time difference. If so, the update is available, otherwise it is not.

The Update Controller property EnableControlledRollout must be set to true to enable controlled rollouts. The default value is false.


Customized Forms

AppLife Update contains a default Check for Updates form and an Update Download Status form. These forms are designed to be aesthetically appealing though generic, allowing for integration into a wide variety of applications. If our default forms do not adequately match your applications visual theme, you can implement your own forms. See the Custom Forms Quick Start for guidance.

More:

Check for Update Form

Download Update Form


Check for Update Form

To implement your own Check for Updates form, you will call a check for update method on the Update Controller and then interrogate the CurrentUpdate property for information about any discovered updates.

There is both a synchronous and asynchronous method to check for updates. The synchronous CheckForUpdates method is a blocking method and returns a boolean value indicating whether an update was found or not. The CheckForUpdatesAsync method is a non-blocking call. You can handle the CheckForUpdateCompleted event to be informed when the asynchronous call completes. The event argument contains a property that indicates whether or not an update was discovered.

With either Check for Update call, if an update is found, information about the update can be utilized by looking at the CurrentUpdate property. If no update is found, the CurrentUpdate property is empty or null.

Note: Please reference the Update Controller API documentation for more information on these methods. Also, please reference the Custom Forms Quick Start project for an example of using custom forms.


Download Update Form

If the standard update download form does not match your application, you can implement your own download form. You do not need to implement a custom download form just because a custom Check for Updates form was implemented. To show the standard download form after utilizing a custom Check for Updates form, you can call the ShowDownloadUpdateDialog method.

To implement a custom download form, you call a download method on the Update Controller. There is both a synchronous and asynchronous download method. When using the asynchronous method, you can subscribe to a progress event and a completion event. Both event handlers are guaranteed to be executed on the same thread that started the download. The progress event handler has an event argument that provides progress information.

After an update is downloaded by using the ShowDownloadUpdateDialog or a call to a download method, you must call ApplyUpdate on the Update Controller to initiate the update process.

Note: Please reference the Update Controller API documentation for more information on these methods. Also, please reference the Custom Forms Quick Start project for an example of using custom forms.


AppLife Update Components

More:

Update Controller

Update Service

Make Update

Make Update Console Application


Update Controller

The Update Controller is a .Net component that can be added to any .Net 2.0 application. The Update Controller exposes properties and methods that you can use to check a network location for any available updates, download an update, and initiate the process of updating the software. The Update Controller can be distributed with your application free of any royalties.


Update Service

The Update Service is a Windows Service that allows for the execution of an update action list with elevated privileges.


Make Update

Make Update is a windows forms application that allows a user to define an update, build an update package, and publish the update package to a network resource. Make Update also allows for the modification of information about available updates.


Make Update Console Application

The AppLifeUpdateCmd.exe console application allows for building and publishing update project files. The console application enables AppLife Update publishing functionality to be integrated into your automated build and packaging processes. See Automating Updates for more information.


Update Actions

Update Actions

AppLife Update Action List updates consist of a list of Update Actions that are executed sequentially. When an update author is defining the update process for their software, Update Actions are used to modify the current installation on deployed clients.

For most applications, the update process consists of adding and replacing assemblies and supporting files. AppLife Update contains a choice of actions that adds and replaces files.

In extending applications it is sometimes necessary to perform additional actions before or after application assemblies and files are replaced. For example, to add a COM component to your application, you will need to place the file, and then register the component on the system. You might also find it necessary to modify a configuration file during an update. AppLife Update contains actions to perform these types of actions as well.

Though there are many built-in actions to perform the most common updating activities, you might also need to perform a specialized action. To perform application specific custom updating activities AppLife Update includes a Custom Action infrastructure that provides the ability to use .Net code to implement your own custom update actions.

More:

Update Action Execution


Update Action Execution

AppLife Updates are performed by the AppLife Update Engine. The update engine is responsible for executing the actions defined in the update project. Each action contains the logic necessary to perform its function. In addition to the actual update process, each action is responsible for ensuring that its work can be rolled back in the event of an unexpected exception anywhere in the update process. To support this, the update engine executes multiple stages within the update process. The stages that the engine executes are:

· Prepare

· Execute

· Cleanup

And in the event that an error occurs, a Rollback stage is executed.

The engine first iterates through each action and executes the Prepare stage. The purpose of this stage is to perform any actions necessary to prepare the client for the work to be done in the Execute stage. This might include backing up files that are to be replaced, checking for specific permissions to perform the tasks, etc.

Once each action has performed its Prepare operations, the action list is iterated, with each action performing its Execute operations. When the final action in the action list successfully completes its Execute operation, the update is considered successful. If an exception occurs before reaching this point, the Update Engine will enter a Rollback stage. During a rollback operation, the actions are iterated in reverse order from the action that caused the exception. In each action, the Rollback operations are performed.

Upon successfully completing the Execute phase, the Update Engine iterates the Cleanup phase. Each action can remove any temporary files or perform any other cleanup operations necessary. No actions actually required to update the client should be performed in the Cleanup stage. An exception in this stage will not cause a rollback operation.

Note: When an action has a conditional statement assigned, the action Prepare method is deferred to execute just before the Execute method. When the execute stage reaches the action, the conditional statement is evaluated. Based on the result of evaluating the conditional expression, the prepare stage method will execute immediately before the Execute method.


Expansion Variables (Shared Properties)

Expansion variables are used to share properties between individual actions of an action list update. Most text-based properties of the AppLife Update Actions can expand variables. Properties that can consume expansion variables are adorned with an [image] icon.

Expansion variables expose the contents of the Update Context Shared Properties collection to the action editors.

A shared property value is placed in an action property by enclosing the key name of the shared property within two dollar sign characters.

Example:

In this example, the target client path value is expanded during update execution to the value of the update context shared property entry “MyPath”.

Expansion variables can be placed as part of a longer explicit value. Such as “$MyPath$\SubDirectory\”

Note: To use a “$” in any property that supports expansion variables as part of a string literal, place a double dollar sign. “$$”.

More:

Setting Shared Property Variables


Setting Shared Property Variables

Shared Property variables can be defined and passed into an update from the host application as an update is being applied. A collection of shared properties can be passed as a parameter to the methods that launch an update from the host application. Some update actions can also set shared properties.

The actions that allow update designers to set shared property variables that can be used in other actions through expansion are:

Set Shared Property

Read Registry Value

Read Xml Node

Transacted Database Query

Transacted Database Stored Procedure

Shared properties can also be set within Dynamic Actions and custom actions. These actions can directly manipulate the Shared Properties collection by using the Update Context object available within the method parameters. This information can then be shared with other update actions by placing expansion variables.


Action Conditionals

Any action in an action list update can have a condition assigned that controls whether or not the action is executed during the update. If no condition is set, the action is always executed.

Action conditions will take the form of an arithmetic statement and evaluate to either true or false. If the conditional expression evaluates to true, the action is executed during the update. If it evaluates to false, the action is skipped and not executed.

The expression can include a combination of values, operators and functions.

Supported Operators

Binary

+, -, *, /, mod, >, <, >=, <=, and, &, or, |, andalso, &&, orelse, ||, xor, ^, like, =, ==, <>, !=

Unary

Not, !, ~, -

Precedence

Standard operator precedence is honored.

1. -; !, not; ~

2. *; /; %, mod

3. +; -

4. >; <; >=; <=

5. ==, =; !=, <>; like

6. &, and

7. ^, xor

8. |, or

9. &&, andalso

10. ||, orelse

Functions

The following functions are supported in action conditional statements.

· Startswith(string, string). Returns 1 if the first string starts with the second string, using case-insensitive comparison.

· Endswith(string, string). Returns 1 if the first string ends with the second string, using case-insensitive comparison.

· Contains(string, string). Returns 1 if the first string contains the second string, using case-insensitive comparison.

· Substring(string, number:start, number:length). Returns text from the first string, from start (0-based) and extending for length characters.

· Append(string, string). Returns a string containing string 1 followed by string 2.

· Round(number). Returns the number rounded to the nearest integer.

· Sign(number). Returns 1 if the number is positive, -1 if the number is negative, or 0 if the number is 0.

· Int(number). Returns the integer part of the number.

· Frac(number). Returns the fractional part of the number.

More:

Creating and Testing Conditionals


Creating and Testing Conditionals

Action conditionals can be defined and tested from within AppLife Make Update using the conditional test dialog. The test dialog allows test values to be assigned to any shared property located within the conditional expression.

After assigning values for Shared Properties, the test command will evaluate the expression and the result is shown.

Any modifications made to the expression in the test dialog are transferred back to the action expression when the dialog is closed.


AppLife Update Actions

More:

Actions and Build Machine Relative File Paths

Files & Folders

AppLife Manager

Operating System

Registry

COM Registration

XML Actions

Services

Sql Server Actions

Database Actions

Shared Properties

Update Category


Actions and Build Machine Relative File Paths

When using file paths on update action editors that point to the local build machine file system, relative paths are supported. The default base path is the location of the aup project file. The base path can be configured within the project properties by setting the Action Base Path. This property can be found on the Build tab of the project settings dialog.


Files & Folders

In addition to the standard .Net special folders, there are folders that you can designate to place files.

Application Directory

The application directory is the directory on the client that contains the assembly that is hosting the AppLife Update Controller. This is usually the primary executable of your application. You can navigate relative to this folder using the subdirectories property.

Update Package Directory

The update package directory is the temporary directory where files are placed during the update process. You can use this location to place files that are used by other actions to accomplish an update task.

Application Data

The directory that serves as a common repository for application specific data for the current roaming user.

System

The operating system directory. This folder target allows you to explicitly place files in this folder.

System (x86)

The win32 subsystem System(x86) directory on x64 operating systems. This folder target allows you to explicitly place files in this folder. When this target folder is encountered on updates running on 32-bit operating systems, the System folder is used.

Common Desktop

The directory physically used to store file objects on the desktop shared between all users.

Common Program Files (x86)

The win32 subsystem Common Files(x86) directory on x64 operating systems. This folder target allows you to explicitly place files in this folder. When this target folder is encountered on updates running on 32-bit operating systems, the Common Files folder is used.

Common Program Files

The system Common Files directory. This folder target allows you to explicitly place files in this folder.

Program Files

The system Program Files directory. This folder target allows you to explicitly place files in this folder.

Program Files (x86)

The win32 subsystem Program Files(x86) directory on x64 operating systems. This folder target allows you to explicitly place files in this folder. When this target folder is encountered on updates running on 32-bit operating systems, the Program Files folder is used.

Common Programs

The directory that contains the program groups shared between all users.

Common Start Menu

The directory that contains the Start Menu items shared between all users.

Update Package Directory

The update package directory is the temporary directory where files are placed during the update process. You can use this location to place files that are used by other actions to accomplish an update task.

Explicit Path

This setting allows you to specify an explicit path on the client for file placement. The Explicit Path settings allow you to set a path from a read action or a custom action into a shared property and use the built-in file actions to perform file updates.

Desktop Directory

The directory that is used to physically store file objects on the desktop.

Local Application Data

The directory that serves as a common repository for application-specific data that is used by the current, non-roaming user.

My Documents

The current users “My Documents” folder.

Recent

The folder that contains the users most recently used documents.

Start Menu

The folder that contains the user scoped “Start Menu” items.

Startup

The user specific startup program folder.

Templates

The folder that contains the user scoped document templates.

More:

Add & Replace Files

Add & Replace Files by Comparison

Add Folder Contents

Create Folder

Delete Folder

Delete Files

Masked Add & Replace Files

Patch Existing File

Patch Folder

Replace Files on Restart

Create File Shortcut


Add & Replace Files

The Add & Replace Files action allows you to add file(s) into a designated folder on the target system. You can choose from a list of target client folders. By default, the Application Directory is where the designated files will be placed.

You can define folders relative to target client folder by setting the subdirectories property.

Files can be added to the list by clicking the Add files button on the right of the list or by selecting the context menu item Add File(s).

The files that are designated must be present for this action to be valid.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Makes a copy of the files that are going to be replaced on the client computer, then adds and replaces the defined list of files on the client.

Cleanup Stage

Removes the backup copies that were made during the execute stage.

Rollback Stage

Attempts to copy the files that were backed up in the execute stage back to their original location.


Add & Replace Files by Comparison

The Add & Replace Files by Comparison action automatically determines the files that need to be added to your update. The action accomplishes this by comparing files from a target folder with those from a baseline folder.

The process of determining files to include in the update is performed while the update package is being built. Files in the target folder that are identical to the baseline folder are skipped, and not added to the update. Information on skipped files is written to the build output.

To include subfolders, check the Include subdirectories option. When subfolders are included, the action will operate recursively to analyze each file in the branch for inclusion. Folders that are not in the baseline folder but in the target folder are created when the update is applied.

Note: Folder permissions are not analyzed. New folders will inherit permissions from their parent on the target client.

To use this action,

1. Prepare a baseline folder that represents a snapshot of the deployed application directory. This baseline should represent the lowest possible application version that this update can target.

2. Prepare a current folder that represents your application directory after this update is applied. This folder is commonly an output of an automated process.

3. Set up the action in Make Update to reference these folders.

4. Build updates.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Makes a copy of the files that are going to be replaced on the client computer, then adds and replaces the defined list of files on the client.

Cleanup Stage

Removes the backup copies that were made during the prepare stage.

Rollback Stage

Attempts to copy the files that were backed up in the execute stage back to their original location.


Add Folder Contents

The Add Folder action creates a folder in the designated target client folder. All files in the local folder are packaged into the update. You can choose to include subdirectories. If subdirectories are included, the inner directories are created on the deployed client and their contents are placed inside of the newly created directories.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Makes a copy of the files that are going to be replaced on the client computer, then adds and replaces the defined list of files on the client.

Cleanup Stage

Removes the backup copies that were made during the execute stage.

Rollback Stage

Attempts to copy the files that were backed up in the execute stage back to their original location.


Create Folder

The Create Folder action creates a new folder on the target system. The full path of the designated folder is created.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Creates the designated directory(s) on the target system.

Cleanup Stage

No action taken

Rollback Stage

Attempts to remove the newly created directories. If any files are in the directories the files and directories will not be removed.


Delete Folder

The Delete Folder action removes the designated folder from the target system. You can optionally delete all files and subdirectories. You can also elect to continue the update if any file or directory deletion fails, or abort the update.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Makes a copy of the files that are going to be deleted on the client computer, then deletes the folder and files on the client.

Cleanup Stage

Removes the backup copies that were made during the execute stage.

Rollback Stage

Attempts to replace the files that were deleted from the backup files created in the execute stage.


Delete Files

The delete files action allows you to remove a list of files from a specific target client folder. To use this action, you set the target client folder from which to remove the file(s) from and you set a list of filenames to be removed.

Wildcard characters are supported in the file list.

No exceptions are thrown if a file listed does not exist on the client.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Makes a copy of the files that are going to be deleted on the client computer, then deletes the files on the client.

Cleanup Stage

Removes the backup copies that were made during the execute stage.

Rollback Stage

Attempts to replace the files that were deleted from the backup files created in the execute stage.


Masked Add & Replace Files

The masked add & replace files action allows you to specify a file mask to use when adding files from your local file system to the update. To use this action, you set the target client folder, provide a local folder to look for files in, and you supply a file mask such as (*.exe).

When this action is processed during the update build process, the mask is applied to the local folder and all files that match the mask are included into the update package. This action is an extension of the add & replace files action

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Makes a copy of the files that are going to be replaced on the client computer, then adds and replaces the defined list of files on the client.

Rollback Stage

Attempts to copy the files that were backed up in the execute stage back to their original location.


Patch Existing File

The Patch Existing File action allows you to compare the current version of a file with a previous existing file, generate a delta file as an update is being created, and then utilizing the delta file and the existing file to create the new file on deployed systems. This action utilizes the Microsoft Delta Compression API to generate the patch file, and re-create the new file starting from the existing file.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

During the execute stage, the original existing file is backed up in case the update must be rolled back. The patch is then applied to the existing file. After the patch is applied, the hash of the resulting file is compared to the hash of the target file that was taken when the update was created. If the resulting file hash does not match, the action fails and a rollback is initiated.

Cleanup Stage

Removes the backup copies that were made during the execute stage.

Rollback Stage

Replaces the target file with the original back up created prior to performing the Execute stage.


Patch Folder

The Patch Folder action allows you to compare all files in a folder with a baseline folder and generate a delta file for each, as an update is being created. Then utilize the delta file, along with the existing file to re-create the new file on deployed systems. This action utilizes the Microsoft Delta Compression API to generate the patch file, and re-create the new file starting from the existing file. Update size can be significantly reduced by using this action.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

During the execute stage, the original existing files are backed up in case the update must be rolled back. The action then uses the patches and applies them to the existing files. After a patch is applied, the hash of the resulting file is compared to the hash of the target file that was taken when the update was created. If any of the resulting file hashes do not match, the action fails and a rollback is initiated.

Cleanup Stage

Removes the backup copies that were made during the execute stage.

Rollback Stage

Replaces all target files with the original back up created prior to performing the Execute stage.


Replace Files on Restart

The Replace Files on Restart action allows you to replace a locked file on the target system upon operating system restart. You can choose from a list of target client folders.

You can define folders relative to target client folder by setting the subdirectories property.

Files can be added to the list by clicking the Add files button on the right of the list or by selecting the context menu item Add File(s).

The files that are designated must be present for this action to be valid.

Prepare Stage

During the prepare stage, this action verifies permissions to the target folder.

Execute Stage

Places the designated files on the client file system in the directory specified, renamed for uniqueness, then appends to the system registry the necessary values to register the file for replacement upon operating system restart.

Cleanup Stage

No action taken.

Rollback Stage

Removes the registry information designating the files to be replaced on restart. Removes the local copies of the files.


Create File Shortcut

The create file shortcut action allows you to create a shortcut on the client during an update. To use this action, you set the location of the shortcut, the target of the shortcut, and any command line arguments.

For this action to be valid, a shortcut location, target location, and if set, an Icon location must be configured.

If the defined shortcut already exists on the client, you can choose to replace it, skip it, or abort the update.

Prepare Stage

During the prepare stage, this action verifies permissions to the shortcut location folder.

Execute Stage

Creates a new shortcut on the client computer. If a shortcut already exists, the original is backed up.

Rollback Stage

If a preexisting shortcut was backed up in the execute stage, this shortcut is restored.


AppLife Manager

More:

Set Application Directory

Set Update Version


Set Application Directory

Searches for a designated assembly or file and updates the AppLife Manager configuration file with the discovered Application Directory. If a specific directory is desired, use the Default value to designate any desired folder as the Application Directory.


Set Update Version

The Set Update Version action updates the AppLife Manager configuration file with version stamp of the executing update. The action can be configured to use the active update version or an explicit value that is defined in the configuration of the update, by using a Shared Property.

Version Source Options:

1. Use active update version (default value) – This option will set the value to the update version of the currently executing update.

2. Set explicit version value – This option will set the value to the configured value defined in the Explicit version value seting

Explicit version value – When the Version Source is configured to use the explicit version, the value defined here is used to set the configuration version value. Shared Property expansion is supported within this setting.


Operating System

More:

Execute MSI

Install .NET 4.0

Restart Operating System

Run Command Line


Execute MSI

The Execute MSI action will utilize the Windows Installer to execute a designated Msi file. This action allows the update author to designate an execute msiexec.exe command line as well as a rollback command line.

To assist in creating the command line, a client path can be designated and assigned to the <path> variable. The designated path can be substituted into the two action command lines with the <path> variable. Shared properties will be expanded into the command lines as well.

Prepare Stage

No action taken

Execute Stage

Executes the Execute command line using msiexec.exe

Cleanup Stage

No action taken.

Rollback Stage

Executes the Rollback command line using msiexec.exe


Install .NET 4.0

The Install .Net 4.0 action installs the .Net Framework 4.0 during an update, if the framework is not already present.

This action uses the Microsoft .Net Framework installer. You can configure the action to include the web installer in the update, include the full installer, or download the installer from a designated location.

As the update action executes, progress can be shown by the AppLife Update user interface, or you can display the Microsoft Framework installer user interface. The Microsoft installer interface can be shown n a passive mode, where the user does not provide any feedback, or in a standard mode.

Note: If you are using the AppLife Update Windows Service for permissions elevation, you must use the Show progress as part of the update option.

If the Framework installer requires a system restart, you can configure the prompt shown to the user.

You can set a shared property if installing the framework requires a system restart. This shared property can then be used to conditionally prevent your application from restarting by using a Prevent Application Restart action and a conditional statement.

Prepare Stage

No action taken

Execute Stage

Checks for the presence of the .Net 4.0 Framework. If the framework is not present, the framework installer is launched as configured in the action properties.

Cleanup Stage

No action taken.

Rollback Stage

No action taken. If the .Net 4.0 Framework is successfully installed, it will not be uninstalled in an update rollback.


Restart Operating System

The Restart Operating System action will cause a system restart to occur after the completion of the update. The update author can optionally prompt the user for permission to restart. If the user chooses to suppress the restart, the action can be configured to abort the update or continue to completion.

Prepare Stage

No action taken

Execute Stage

Configures the update engine to initiate a system restart at the completion of the update.

Cleanup Stage

No action taken.

Rollback Stage

Ensures no restart will occur.


Run Command Line

The Run Command Line action executes the designated command line on the client system. For convenience, the action supports designating two paths for use within the command line.

Prepare Stage

No action taken

Execute Stage

Executes the Execute command line using an operating system shell.

Cleanup Stage

No action taken.

Rollback Stage

Executes the Rollback command line using an operating system shell.


Registry

More:

Create Registry Key

Set Registry Values

Delete Registry Key

Delete Registry Values

Read Registry Value


Create Registry Key

The Create Registry Key action creates a registry key on the target client. To use this action, you select the registry hive and provide a path to the key that you would like to create. If keys in the defined path do not exist, the action will create them.

Prepare Stage

No action taken

Execute Stage

The action creates the defined registry key if it doesn’t already exist.

Cleanup Stage

No action taken.

Rollback Stage

The action deletes the defined registry key if it didn’t already exist prior to initiating the update.


Set Registry Values

The Set Registry Values action sets or creates a list of registry values within a single key. When adding values to a registry key that is being created within the same update, the Create Registry Key action must precede the Set Registry Values action.

To use this action, you select the registry hive and then provide a path to the key that contains the values that will be set. This key must already exist. Then provide an entry for each value that will be set. For each entry, set the Name, value type and the value to place.

Prepare Stage

During the prepare stage, this action checks permissions to write to the defined registry location.

Execute Stage

This action backs up the current values then writes the new registry values.

Cleanup Stage

No action taken.

Rollback Stage

Restores registry values that were backed up in the execute stage and removes any newly added values that were not present.


Delete Registry Key

The Delete Registry Key action deletes a defined registry key and all its values. To use this action you select the registry hive and define the path to the key that is to be removed.

This action will not remove sub keys. The key being removed cannot contain sub keys. If the key contains sub keys, this action will fail.

If the defined key does not exist, no errors are raised.

Use caution when deleting registry keys.

Prepare Stage

During the prepare stage, this action checks delete permissions of the defined registry location.

Execute Stage

This action backs up the defined registry key, then deletes if it exists.

Cleanup Stage

No action taken.

Rollback Stage

Restores registry key as it was backed up in the execute stage.


Delete Registry Values

The Delete Registry Values action removes one or more values from a designated registry key. To use this action you select a registry hive and define a path to the key that holds the values that are to be removed. This key must exist. Then you provide a list of value names that are to be removed. The match is case insensitive. If a defined value is not found the action continues without raising an error.

Use caution when deleting values from the registry.

Prepare Stage

During the prepare stage, this action checks delete permissions of the defined registry location.

Execute Stage

This action backs up the registry values then deletes the defined registry values, if they exist.

Cleanup Stage

No action taken.

Rollback Stage

Restores registry values that were backed up in the execute stage.


Read Registry Value

The Read Registry Values action reads a defined value from the registry and places the value read from the registry into the Shared Properties collection with the key name provided.

Prepare Stage

During the prepare stage, this action checks read permissions of the defined registry location.

Execute Stage

This action backs up the value of the defined Shared Property, then reads the registry value and sets the Shared Property value.

Cleanup Stage

No action taken.

Rollback Stage

Restores the Shared Property value that was backed up in the execute stage.


COM Registration

More:

Register Assembly

Register Library

Unregister Library


Register Assembly

The Register Assembly action allows you register a .Net assembly for COM interop by using the Regasm.exe application.

Please reference Microsoft’s documentation on Regasm.exe for more information.

The file action that places the assembly being registered must precede this action.

Prepare Stage

No action taken.

Execute Stage

Calls Regasm.exe to register the library using the defined Execute command line.

Cleanup Stage

No action taken.

Rollback Stage

Calls Regasm.exe to unregister the assembly using the defined Rollback command line.


Register Library

The Register Library action allows you register a COM assembly by using the regsvr32 application program interface. To use this action, you provide the path to the COM assembly that you want to register. You can also select to use DllInstall, use DllRegiserServer or use both. The default action is to use DllRegisterServer. This action allows you to define whether the COM assembly should be registered as a 32-bit or 64 bit assembly on 64-bit operating systems.

Please reference Microsoft’s documentation on RegSvr32.exe for more information.

The file action that places the assembly being registered must precede this action.

Prepare Stage

No action taken.

Execute Stage

This action calls RegSvr32.exe to register the library using the defined options.

Cleanup Stage

No action taken.

Rollback Stage

Attempts to call RegSvr32.exe to unregister the assembly using the defined settings.


Unregister Library

The UnRegister Library action allows you unregister a COM assembly by using the regsvr32 application program interface. To use this action, you provide the path to the COM assembly that you want to unregister. You can also select to use DllInstall, use DllUnRegiserServer or use both. The default action is to use DllUnRegisterServer. This action allows you to define whether the COM assembly being unregistered is a 32-bit or 64 bit assembly on 64-bit operating systems.

Please reference Microsoft’s documentation on RegSvr32.exe for more information.

The file action that places the assembly being registered must precede this action.

Prepare Stage

No action taken.

Execute Stage

This action calls RegSvr32.exe to unregister the library using the defined options.

Cleanup Stage

No action taken.

Rollback Stage

Attempts to call RegSvr32.exe to register the assembly using the defined settings.


XML Actions

More:

Add Element

Add Attribute

Change Node

Delete Node

Read Node


Add Element

The Add Element action adds an Xml element to an existing xml document. To use this action you provide a path to an existing Xml Document by selecting from a list of known folders on the client target and then providing a sub path and file name.

You then provide an XPath expression to identify the parent element that the new element will be added to. If more than one element matches the Xpath expression, you can choose one of five actions:

· Add the element to all nodes (the default action)

· Add the element to only the first node found

· Add the element to only the last node found

· Don’t add any elements

· Abort the update

Once the parent node is found, you can choose to add the new element at the beginning (before siblings) or at the end (after siblings) of the parent document element.

A new element is added at this location using the element name provided. If a value is provided, the text will be placed inside opening and closing tags.

If an element already exists that matches the element being added, you can choose take one of four actions:

· Insert the new element, ignoring any previous ones (The default action)

· Delete any existing elements, then insert the new one

· Do not insert the element

· Abort the update

This action requires a full path to an xml file, defined by setting a target client folder, any appropriate sub path information and a file name. In addition to the full file path, the element name must be provided. The element value is optional.

A list of Attributes can be defined, which will be added to the newly created element.

Prepare Stage

Verifies permissions to modify the xml file.

Execute Stage

Backs up the xml file then inserts the new xml element, performing the operation as defined by the action properties.

Cleanup Stage

Removes the backup file created during the execute stage.

Rollback Stage

Restores the xml file with the file backed up in the execute stage.


Add Attribute

The Add Attribute action allows you to add an attribute to a specific Xml element. To use this action you provide a path to an existing Xml Document by selecting from a list of known folders on the client target and then providing a sub path and file name. If the attribute already exists, the value will be modified to match the configured setting.

You then provide an XPath expression to identify the element that the new attribute will be added to. If more than one element matches the XPath expression, you can choose one of five actions:

· Add the attribute to all nodes (the default action)

· Add the attribute to only the first node found

· Add the attribute to only the last node found

· Don’t add any attributes

· Abort the update

You provide the name and value of the new attribute and it is added to the element based on the setting above.

Prepare Stage

Verifies permissions to modify the xml file.

Execute Stage

Backs up the xml file then inserts the new xml attribute, performing the operation as defined by the action properties.

Cleanup Stage

Removes the backup file created during the execute stage.

Rollback Stage

Restores the xml file with the file backed up in the execute stage.


Change Node

The Change Node action replaces the value of an xml node found using an XPath expression. The node can be an attribute or an element. To use this action you provide a path to an existing Xml Document by selecting from a list of known folders on the client target and then providing a sub path and file name.

You then provide an XPath expression to identify the node that you want to change. If more than one node matches the XPath expression, you can choose one of five actions:

· Change all nodes (the default action)

· Change only the first node found

· Change only the last node found

· Don’t change any nodes

· Abort the update

You provide the new node text and nodes are changed based on the setting above.

Prepare Stage

Verifies permission to modify the defined Xml file.

Execute Stage

The action backs up the Xml file then changes the Xml node text, performing the operation as defined by the action properties.

Cleanup Stage

Removes the backup file created during the execute stage.

Rollback Stage

Restores the xml file with the file backed up in the execute stage.


Delete Node

The Delete Node action removes an element or an attribute from a specified Xml file. To use this action you provide a path to an existing Xml Document by selecting from a list of known folders on the client target and then providing a sub path and file name.

You then provide an XPath expression to identify the node that you want to remove. If more than one node matches the XPath expression, you can choose one of five actions:

· Delete all nodes (the default action)

· Delete only the first node found

· Delete only the last node found

· Don’t delete any nodes

· Abort the update

Prepare Stage

Verifies permissions to modify the Xml file.

Execute Stage

The action backs up the Xml file then deletes the Xml node, performing the operation as defined by the action properties.

Cleanup Stage

Removes the backup file created during the execute stage.

Rollback Stage

Restores the xml file with the file backed up in the execute stage.


Read Node

The Read Node action reads a defined value from an Xml file and places the value read into the Shared Properties collection with the key name provided.

Prepare Stage

During the prepare stage, this action checks read permissions of the defined Xml file.

Execute Stage

This action backs up the value of the defined Shared Property, then reads the Xml node value and sets the Shared Property value.

Cleanup Stage

No action taken.

Rollback Stage

Restores the Shared Property value that was backed up in the execute stage.


Services

More:

Start Service

Stop Service

Replace Public Key


Start Service

The Start Service action starts a windows service on the target client. To use this action, you provide the service name and any arguments that the service expects. The action will start a stopped or paused service. If the service is already running the default action is to do nothing. Alternatively, you can select to force the service to restart. If the service does not exist on the target, the update will fail.

Prepare Stage

No action taken.

Execute Stage

The action starts the designated service.

Cleanup Stage

No action taken.

Rollback Stage

If the service was stopped when the action executed, the service is stopped.


Stop Service

The Stop Service action stops a windows service on the target client. To use this action, you provide the service name that you want to stop. The action will stop a running or paused service. If the service is already stopped, the action will do nothing. If the service does not exist on the target, the update will fail.

Prepare Stage

No action taken.

Execute Stage

The action stops the designated service. Any dependent services will also be stopped.

Cleanup Stage

No action taken.

Rollback Stage

If the service was running when the action executed, the service is restarted. Any dependent services are also restarted


Replace Public Key

The Replace Public Key action unregisters your current application public key from the client and registers a new public key in its place. Use this action if you have deployed the AppLife Update service and need to switch application key pairs.

Prepare Stage

No action taken

Execute Stage

Replaces the current public key with the newly designated public key within the AppLife Update Service registry.

Cleanup Stage

No action taken.

Rollback Stage

Restores the original public key that was replaced during the execute stage.


Sql Server Actions

More:

Backup SQL Server Database

Begin SQL Server Transaction

Close SQL Server Connection

Commit SQL Server Transaction

Open SQL Server Connection

Run SQL Server Query


Backup SQL Server Database

This action initiates a backup of the defined SQL Server database, using the defined backup device. Note that a backup cannot be performed inside of a transaction.

Prepare Stage

No action taken.

Execute Stage

Backup is performed.

Cleanup Stage

No action taken.

Rollback Stage

No action taken.


Begin SQL Server Transaction

This action creates a SQL Server transaction using the defined SQL Server Connection. The transaction can then be used by one or more Run SQL Server Query actions within the action list. The transaction object can also be accessed by custom or dynamic code actions through the Update Context object’s Shared Properties collection.

Prepare Stage

No action taken.

Execute Stage

Creates a SQL Server transaction and adds the transaction to the Update Context Shared Properties collection.

Cleanup Stage

No action taken.

Rollback Stage

If the transaction has not been committed, the transaction is rolled back.


Close SQL Server Connection

This action closes the designated SQL Server connection.

Prepare Stage

No action taken.

Execute Stage

The SQL Server connection is closed and disposed.

Cleanup Stage

No action taken.

Rollback Stage

No action taken. A closed connection cannot be re-opened.


Commit SQL Server Transaction

This action commits the defined SQL Server Transaction.

Prepare Stage

No action taken.

Execute Stage

The SQL Server transaction is committed.

Cleanup Stage

No action taken.

Rollback Stage

No action taken. A committed transaction cannot be rolled back.


Open SQL Server Connection

This action opens a SQL Server connection using the defined connection string, and adds the connection to the Update Context Shared Properties collection. Other SQL Server update actions can use the connection. The connection can also be accessed from custom or dynamic code action through the Update Context Shared Properties collection.

The connection string can be read from a .net config file, or defined explicitly. Shared properties can also be used to define the connection string. Using Shared Properties, the connection string can be passed in from the host application using an ApplyUpdate method overload, or retrieved from the host computer using an xml or registry action and assigned to a Shared Property, which can be used to define the connection string.

The connection can be designated to be exclusive by placing the database in single-user mode prior to opening the connection.

Prepare Stage

No action taken.

Execute Stage

The SQL Server connection is opened and added to the Shared Properties collection. If designated, the database is placed in single user mode.

Cleanup Stage

No action taken.

Rollback Stage

If the connection is present and still open, the connection is closed. Otherwise no action is taken.


Run SQL Server Query

This action executes a SQL Server query using a designated SQL Server Connection or Transaction. The SQL query text can be specified directly, defined using a Shared Property, or defined by selecting a file during the update build process.

Prepare Stage

No action taken.

Execute Stage

Execute the defined SQL query.

Cleanup Stage

No action taken.

Rollback Stage

No action taken.


Database Actions

More:

Begin Database Transaction

Commit Database Transaction

Transacted Database Query

Transacted Stored Procedure


Begin Database Transaction

Opens a database connection on the defined database and creates a transaction that can be used by the Transacted Database Query and the Transacted Stored Procedure action to perform work on a database during an update process. The transaction is committed and closed using the Commit Database Transaction action.

For this action to be valid the following must be true:

· A Commit Database Transaction action must follow it in the action list

· A connection string must be defined

· A data provider must be defined

Prepare Stage

No action taken.

Execute Stage

Uses provider independent framework classes to open a database connection and start a transaction. The transaction is placed in the update context shared properties collection with the defined key name. The transaction can then be used by other actions as well as custom actions. The DbProviderFactory is also placed in Shared Properties using the transaction itself as a key. Implementers can utilize this object from within their custom actions.

Cleanup Stage

No action taken.

Rollback Stage

Rolls back the transaction started in the execute stage. Removes the transaction and the DbProviderFactory from Shared Properties.


Commit Database Transaction

Commits a transaction started by a Begin Database Transaction action. Once a transaction is committed, it cannot be rolled back.

For this action to be valid, the transaction name must be defined and this action must follow a Begin Database Transaction with a matching transaction name.

Prepare Stage

No action taken.

Execute Stage

Commits the defined database transaction.

Cleanup Stage

No action taken.

Rollback Stage

No action taken. A committed transaction cannot be uncommitted.


Transacted Database Query

This action executes a query on a database defined by the designated database transaction. The query text can be explicitly entered or read from a file. If desired, the results of the database query can be placed in a Shared Property.

For this action to be valid, the transaction name must be defined and this action must follow a Begin Database Transaction with a matching transaction name. Query text or a query file must also be specified.

Prepare Stage

No action taken.

Execute Stage

Backs up the previous output property, if needed.

Runs the specified query on the defined database transaction.

Cleanup Stage

No action taken.

Rollback Stage

Restores the previous output property value, if needed.


Transacted Stored Procedure

This action executes a defined stored procedure on the designated database transaction. You provide a transaction name, stored procedure name, and necessary parameters to execute the stored procedure.

For this action to be valid, the transaction name must be defined and this action must follow a Begin Database Transaction with a matching transaction name. The stored procedure name must also be specified.

Prepare Stage

No action taken.

Execute Stage

Backs up the previous output property value, if needed.

Runs the specified stored procedure on the defined database transaction.

Cleanup Stage

No action taken.

Rollback Stage

Restores the previous output property value, if needed.


Shared Properties

More:

Set Shared Property


Set Shared Property

Adds or replaces a Shared Property value within the Update Context Shared Property collection.

Prepare Stage

No action taken.

Execute Stage

Backs up the original value if one exists, then sets or replaces the Shared Property value with the defined new value.

Cleanup Stage

No action taken.

Rollback Stage

Replaces the original value of the defined Shared Property if necessary.


Update Category

More:

Comment

Dynamic Code Action

Prevent Application Restart

Run Action List


Comment

This action does not perform any action in an update. Use the action to add comments to your Make Update action list.

Prepare Stage

No action taken.

Execute Stage

No action taken.

Cleanup Stage

No action taken.

Rollback Stage

No action taken.


Dynamic Code Action

This action provides a code editor to define updating activity in .Net source code. The custom action class that is defined using this action must implement the Execute method and the Rollback method. The update work performed in the Execute method should be undone in the Rollback method.

Additional methods that can be implemented are:

Prepare

Cleanup

RollbackPrepare

Progress and textual information can be sent to the Update Engine user interface for user presentation by using the OnProgressChanged method.


Prevent Application Restart

The prevent application restart action will ensure that your application will not restart after the update completes.

Prepare Stage

No action taken.

Execute Stage

Configures the update engine to suppress the application restart, regardless of the Update Controller setting within the host application.

Cleanup Stage

No action taken.

Rollback Stage

Configures the update engine to use the restart setting from the Update Controller within the host application.


Run Action List

This action calls an alternate action list. When an action list is inserted, the actions specified within the action list will be executed at the insertion point. During an update build, inserted action lists will be checked for cyclic recursion. The build will fail if an action list is called from within itself without a condition applied.

Prepare Stage

No action taken. All actions in an action list will have their prepare stage deferred. Each action’s Prepare stage will run at the insertion point of the Execute stage, but before any action’s Execute stage.

Execute Stage

Iterates and runs the Prepare stage for all actions in the action list. Then iterates and runs the Execute stage.

Cleanup Stage

Runs the Cleanup stage for all action list actions that were executed.

Rollback Stage

Runs the Rollback stage for all action list actions that were executed.


Making Custom Actions

More:

What Are Custom Actions?

Update Action Configuration and State

Update Action Methods

Update Context

Progress Updates

Custom Action Builder

Adding Custom Actions to Your Project


What Are Custom Actions?

Custom actions are .Net classes that derive from an abstract Kjs.AppLife.Update.Engine.Core.UpdateAction class. This class is located in the Kjs.AppLife.Update.Core.dll. Custom actions can be written in any .Net language and can utilize the entire .Net framework to accomplish the functions for which they are being built. The AppLife Update Engine processes your custom actions just as it processes the built-in actions. At a minimum, a custom action must implement an Execute method and a Rollback method. You can do much more with custom actions though, such as build a custom builder that enforces rules during the update build process, interact with other actions through the UpdateContext object, build a custom user interface to configure the action within Make Update, manipulate the progress bar shown to the user while your custom action executes, and create custom palettes to organize your custom actions within the Make Update user interface.

Custom Actions essentially allow you to implement any actions that you need in order to update and maintain your software in a simple, intuitive and easy to use framework. Please reference the Custom Actions Quick Start to quickly learn how to create and implement custom actions.


Update Action Configuration and State

Most useful actions will require some configuration by the implementer of the action. You configure your custom actions by implementing public properties on your custom action class. Doing so allows the Make Update application to persist your actions using Xml serialization. In addition, you can configure your custom action with the default Action Builder. This builder uses a property grid to manipulate your public properties. While it is not normally necessary, you can extend this interface by implementing type converters, custom editors and other standard Property Grid extension techniques. Alternatively, you can implement your own Custom Action Builder and/or Custom Action Editor. These classes allow you to better control how your custom actions interact with the update build process.


Update Action Methods

The Update Build Engine process actions sequentially and in stages. Building a custom action that participates with the build engine simply requires you to override the virtual methods on the abstract UpdateAction class. To perform prep work during the prepare stage, override the Prepare method within your custom class. The methods that can be overridden are:

· Prepare

· Execute

· Cleanup

· RollbackExecute

· RollbackPrepare


Update Context

Each of the methods that can be overridden contain an UpdateContext parameter. This context object allows your custom actions to interact with the update process. Using the context object, your action methods have access to:

· Application Directory
This is the path on the target client that contains the assembly hosting the Update Controller.

· Update Package Directory
This is the path on the target client to the temporary folder. Actions can place files here or read from files that other actions have placed. It is a temporary working directory for the update process.

· Log
The reference to the Log object allows you to write output to the text log file. This is primarily for diagnostic information.

· Shared Properties
The shared properties reference exposes a dictionary that allows you to place object references that can be consumed in other actions, or conversely, access objects that you have placed from other actions.

· State
The state reference allows you to get the current state of the update that is in progress. Possible values include Prepare, Execute, Cleanup, RollbackExecute, RollbackPrepare.


Progress Updates

From within your custom action, you can call the OnProgressChanged method. This method raises a progress changed event that affects the progress indication on the Update user interface. Use this method to report progress between 0 and 100% of your custom action.


Custom Action Builder

A Custom Action Builder class allows you to control how your action interacts with the AppLife Make Update application and the update build process. Custom Action Builders are not required in order to create and implement custom actions. For most situations, and especially actions that will be used only once, the default Action Builder will provide all that is needed. When you have authored an action that is intended for extensive use, or to be used by other developers, creating a custom action builder allows you provide a more robust and intuitive interaction with Make Update.

The reasons you will implement a Custom Action Builder are:

· You want to validate the properties of your action before an update can be built and published.

· You want to implement a custom user interface to configure your action.

· You want to change the name and icon that Make Update displays when interacting with your action.

· You want to implement a pre and/or post build action around your action.

A Custom Action Builder is a class that inherits from the Kjs.AppLife.Update.Engine.Core.Design.ActionBuilder class. This class is located in the Kjs.AppLife.Update.Engine.Core.Design.dll. Refer to the F1 help for implementation details of the methods and properties of this class.

To link your custom action to its corresponding action builder, you add an ActionBuilderAttribute to your custom action class declaration that specifies your action builder.

From within the action builder, you can reference the action itself with the base class Action property.

Adding Validation

Overriding the ValidateActionCore method allows you to evaluate your action for a valid configuration. This method is called by Make Update when the project is validated. To indicate that your action is not valid, simply add a string description to the errors parameter. This description will be used within the Make Update user interface to indicate the action is invalid and prevent an update package from being built.

Adding a Custom User Interface

The default Action Builder utilizes a property grid to allow you to set the public properties of your custom action.

You can implement your own interface by creating a .Net control or user control.

The control needs to derive from System.Windows.Forms.Control. You should implement a property within your control that allows setting a reference to your Custom Action Builder from outside the user control. This reference will provide all the programmatic access you need from the user control code to interact with your action and Make Update.

The ActionBuilder’s Action property lets you change the state of the action as the user interface elements are manipulated.

Make Update is interested in knowing when the actions within the project have changed and when the actions become valid and invalid. When your user control changes action property values, you should call the SetActionDirty method of the Action Builder. Additionally, when the user control changes values that could affect the validation state of your custom action, you should call the ValidateAction method of the Action Builder.

To connect your custom editor to your action, you override the StartEditingAction method and use the IWindowsFormsActionEditorService to show your custom control in place of the default editor. Use F1 help on this method for additional assistance and an example of how this is performed.

Changing the Action Name and Icon

When you create a custom action, Make Update uses the class name and a default icon to display your action within the Make Update action list. You can change this behavior by setting the DisplayText and Image properties of your custom action builder.

Build Actions

Using a custom action builder, you can perform operations in a pre and post build action. These events occur before and after an update package is built. To use these events for special processing, you override the PrepareForBuild method and/or the CleanupAfterBuild method. Both methods have access to a Build Context object. Using the Build Context object, you can write to the build log by using the Log property. You also can access the project build folder using the BuildDirectory property.

Note: Custom Actions, Custom Builders and Custom Editors do not have to be in the same assembly. The assembly that contains your Custom Actions is included in any update package that utilizes those actions, as your update execution logic resides there. Builders and editors are not used during the update process on the target client. If your builders and editors are in the same assembly as your actions and they significantly increase the size of the assembly, you might consider placing them in a separate assembly to decrease the update package size.


Adding Custom Actions to Your Project

More:

Custom Action Assemblies

Palettes

Custom Action Placeholders

Replacing Custom Action Assemblies


Custom Action Assemblies

Custom Action classes are compiled into your custom action assemblies. You can add these custom assemblies to individual projects, making the actions contained in them available to specific projects. Alternatively you can place the assemblies into the global custom actions folder, making the actions available to all projects.

Adding to a Project

Open your project in Make Update. Under the Tools menu, click the Custom Actions menu item. The Custom Actions form displays the assemblies that are available to the project. To add a new assembly, click the Add an assembly button and browse to your assembly. When an assembly is added, Actions within the assembly will appear in the Make Update Actions palette. You can control the location and display within the actions palette using attributes on your custom actions. See the palette section for more information.

Adding to the Custom Actions Folder

Placing your custom action assemblies within AppLifeUpdateInstallFolder\MakeUpdate\CustomActions folder makes your actions available to all projects. The default location of this folder is C:\Program Files\AppLife Update\MakeUpdate\CustomActions. Assemblies in this folder are visible from the Custom Actions form and the actions will be in the palette.


Palettes

Actions within custom action assemblies are placed in the Action palettes within Make Update. Users can then add these actions to the update projects by interacting with the palette, just as the built in actions are added. Custom Action developers can control the placement within the action palettes by placing attributes on the custom action class declaration.

By default, all custom actions are placed in a palette labeled Misc. Actions are named by their class name and they have a standard action icon.

To control the display and placement, there are three attributes that you place on your action class declaration.

System.ComponentModel.DisplayNameAttribute

System.ComponentModel.DescriptionAttribute

System.Drawing.ToolboxBitmapAttribute

Use the DisplayName attribute to change the display name of the action. Use the Description attribute to change the tooltip on the action. Use the ToolboxBitmap attribute to change the icon for the action.

Using these attributes…

                               [DisplayName("Add Text File"), Category("Sample Actions")]

                               [Description("This is a sample custom action")]

                               [ToolboxBitmap(@"P:\~Scratch\RadialChartHS.png")]

                               public class AddTextFileAction : UpdateAction

Causes the action to be displayed…


Custom Action Placeholders

When Custom Actions are used in an AppLife Update project, their properties are persisted into the project file when the project file is saved. When a project is reopened, Make Update must be able to load the assemblies that contain the custom actions that are in the project. If Make Update cannot find a custom action assembly, a placeholder is inserted into the project that maintains the integrity of the custom action property information. You can then locate the appropriate custom action assembly manually. After the assembly is found and loaded, the placeholders are automatically replaced with the appropriate custom action.


Replacing Custom Action Assemblies

AppLife Make Update loads each custom action assembly that is being used in a project. To replace the assemblies in their current location, you will need to close Make Update. When you re-launch Make Update, custom action assemblies in the same location with the same or newer assembly version numbers will be automatically loaded.


Command Line Utility

AppLife Update includes a console application that allows you to automate performing build and publish operations on a specified AppLife Update project file (.aup)

You can use this console application to integrate AppLife Update build operations into your automated build process. You can also add script to a post-build action in Visual Studio to automate publishing an update for a given build configuration.

More:

Command Line Utility Location

Using the Command Line Utility


Command Line Utility Location

The AppLife Update console application is located in the installation directory.

[InstallDir]\Make Update\AppLifeUpdateCmd.exe


Using the Command Line Utility

The console application is located at:

[InstallDir]\Make Update\AppLifeUpdateCmd.exe

Usage:

AppLifeUpdateCmd <project file> [<update version>] /publish:<location> [options]

<project file> The project file (aup) to be built.

<update version> The version of the update to be built from the project.

<location> Specifies a location to publish the update after building it. <location> can be either the name of a location from the project, or a directory. The update can be published to multiple locations by including multiple /publish options. If no /publish option is specified, the update will be published to the last set of locations specified from the Make Update application. To specify location logon credentials, add /username:<username> and /password:<password> options immediately after the publish location.

Options:

/targets:<target list> Replaces the target versions in the project with the specified list of target versions. Versions can be prefixed with ‘>’ (e.g. “>5.0.0.0) to indicate that any higher versions are also valid. Instead of a target list, “All” or “last” can also be specified. “All” replaces the project’s target list with the “(all)” target, allowing any previous version to be updated. “Last” replaces the project’s target list with the last saved update version.

/summary:<file> Replaces the summary text in the project with the contents of the specified file.

/customdata:<file> Replaces the custom data in the project with the contents of the specified file.

/availability:[normal|test] Sets the availability of the current update in the project to normal or test.

/actionbase:<directory> Sets the base directory used by update actions that support relative file paths.

/licensekey:<key> Use the provided license key. Use when build process is running as an agent, or under a non-interactive user.

/silent Suppresses all output.

/? Displays help information


MSBuild Task

AppLife Update ships with an MSBuild task to integrate into build automations that use MSBuild. The assembly that includes the MSBuild task is located at:

{AppLife Update Install Dir}\Build Automation Utilities\MSBuild\Kjs.AppLife.Update.BuildUpdateTask.dll

More:

Usage


Usage

BuildUpdate Task

Creates and publishes an update, given an AppLife Update project and (optionally) locations to publish the update.

Parameters

ProjectFile

Required String parameter.

Specifies the AppLife Update project used to create the update.

UpdateVersionSource

Optional String parameter.

Specifies the update’s version. This parameter can either be a version (e.g. “2.1.0”) or the path to a built .NET assembly. If it is a path to an assembly, the update’s version will be set to the assembly version of that file.

NOTE: When the AppLife Project configuration links the next update version to a specific file’s assembly or file version, this attribute must be omitted. Otherwise, this attribute should be included.

PublishLocations

Optional ITaskItem[] parameter.

Specifies the locations to which the update will be published. If no locations are specified, the set of locations used last time an update was created in the project are reused.

If <UserName> or <Password> metadata is associated with a location, it will be used to log in to that location.

TargetType

Optional String parameter.

Determines what versions the created update can be applied to.

Current reuses the last-used target version list in the project.

All causes the update to apply to all versions.

Last causes the update to target only the version of the last created update.

Custom sets the target list to the value of the CustomTargets parameter.

CustomTargets

Optional String parameter.

A comma-delimited list of the versions the update will target, if TargetType is set to Custom. Versions can be prefixed with a “>” symbol to indicate that any higher versions should also be targeted.

For example, “2.0,3.0,>5.0” would cause the update to target version 2.0, version 3.0, version 5.0 and any version higher than 5.0.

SummaryFile

Optional String parameter.

Specifies the location of a text file containing summary information about the update.

CustomDataFile

Optional String parameter.

Specifies the location of a text file containing custom data to be included with the update.

TestOnly

Optional Boolean parameter.

Specifies whether the update will be only available to testers, or available to all users.

ActionBaseDirectory

Optional String parameter.

Specifies a directory to be used as the base directory for some file actions.

AppLifeUpdateCmdLocation

Optional String parameter.

Specifies the directory where AppLifeUpdateCmd.exe is located. If AppLife Update is installed on the system where this task is used, this command should not be needed.

Examples

To use this task in your project, you must include a UsingTask element in your build file, usually .csproj or .vbproj (<AppLifeUpdatePath> should be replaced with the location of AppLife Update):

<UsingTask AssemblyFile="<AppLifeUpdatePath>\Kjs.AppLife.Update.BuildUpdateTask.dll" TaskName="Kjs.AppLife.Update.MSBuild.BuildUpdate" />

This will allow you to use the task later in your project.

The following example demonstrates publishing an update to two locations saved in a project file, named “InternalServer” and “PublicUpdateServer”:

<Project xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 ">

       <UsingTask AssemblyFile="<AppLifeUpdatePath>\Kjs.AppLife.Update.BuildUpdateTask.dll" TaskName="Kjs.AppLife.Update.MSBuild.BuildUpdate" />

<Target Name="CreateUpdate">

              <BuildUpdate

ProjectFile="UpdateProject.aup"

                     UpdateVersionSource="4.0.0"

                     PublishLocations="InternalServer;PublicUpdateServer" />

       </Target>

</Project>

The following example demonstrates publishing an update to one explicitly specified location that requires credentials:

<Project xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 ">

       <UsingTask AssemblyFile="<AppLifeUpdatePath>\Kjs.AppLife.Update.BuildUpdateTask.dll" TaskName="Kjs.AppLife.Update.MSBuild.BuildUpdate" />

<ItemGroup>

              <PublishUpdate Include=" http://example.com/updates/myproject/ ">

                     <UserName>ExampleUser</UserName>

                     <Password>ExamplePass</Password>

              </PublishUpdate>

       </ItemGroup>

<Target Name="CreateUpdate">

              <BuildUpdate

ProjectFile="UpdateProject.aup"

                     UpdateVersionSource="4.0.0"

                     PublishLocations="@(PublishUpdate)" />

       </Target>

</Project>

The following example demonstrates how to modify a Visual Studio project file so that updates are created automatically as part of the build process:

<Project DefaultTargets="Build" xmlns=" http://schemas.microsoft.com/developer/msbuild/2003 ">

       <!-- Project content, including PropertyGroups, ItemGroups, etc. is omitted here for brevity. -->

       <Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />

       <!--

<Target Name="BeforeBuild">

</Target>

-->

       <<UsingTask AssemblyFile="<AppLifeUpdatePath>\Kjs.AppLife.Update.BuildUpdateTask.dll" TaskName="Kjs.AppLife.Update.MSBuild.BuildUpdate" />

       <ItemGroup>

              <PublishUpdate Include=" http://example.com/updates/myproject/ ">

                     <UserName>ExampleUser2</UserName>

                     <Password>ExamplePass2</Password>

                     <InProject>false</InProject>

                     <!-- The InProject metadata must be set to false to prevent

                            this location from appearing in Solution Explorer. -->

              </PublishUpdate>

              <PublishUpdate Include="InternalServer">

                     <Password>ExamplePass</Password>

                     <InProject>false</InProject>

              </PublishUpdate>

       </ItemGroup>

       <Target Name="AfterBuild">

              <!-- Specify a Condition attribute on the BuildUpdate task to ensure that we only create

                     updates when building in a specific configuration-- in this case, "Release." -->

              <BuildUpdate

                     Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' "

ProjectFile="UpdateProject.aup"

                     UpdateVersionSource="$(OutputPath)\$(AssemblyName).exe"

                     TestOnly="false"

                     PublishLocations="@(PublishUpdate)" />

       </Target>

</Project>


FinalBuilder Action

An action for VSoft’s FinalBuilder build automation product is included.

The fbap file that includes the action is located at:

{AppLife Update Install Dir}\Build Automation Utilities\FinalBuilder\AppLifeActions.fbap

Notes:

This AppLife Update Finalbuilder action simplifies using the AppLife Update command line utility from VSoft's Finalbuilder build tool.

Place the AppLifeActions.fbap file into your finalbuilder [InstallDir]\ActionDefs folder.

Under the .Net Tools palette you will find a Build AppLife Update Project action. The location of the AppLifeUpdateCmd.exe is set under the Actions tools menu.

All of the command line utility features are exposed through the action interface.

You can find more information about Finalbuilder here: http://www.finalbuilder.com/


Kinetic Jump Support

More:

Email Support

Phone Support

User Forums


Email Support

Email questions to techsupport@kineticjump.com

Email questions will be answered within 2 business days. Most questions are answered within just a few hours.


Phone Support

Available from 9AM – 5PM CST Monday thru Friday. Dial 952-496-2921. Phone support is free for one year following the purchase of a license. Outside of that period, phone support is charged per incident.


User Forums

http://www.kineticjump.com/forums


New Project Wizard

What is your application called?

Enter a friendly name that you can refer to this application by.

Where will your updates be hosted?

Path your application will use to find updates:

Enter the network location that that your application can download updates from. This network folder can be an http, ftp, UNC, or file path location. It must be dedicated to this application.

Path you will use to publish updates:

This location will be used to publish updates. You can use a different protocol to publish updates than you use to download. It is common to use http for downloading updates, and use ftp or a file path for publishing updates.

Verifying Paths

You can use the Verify utility to create the update location if it doesn’t already exist, and ensure that the download path and publish path are directed to the same directory.

More:

Program Versioning

Update Process Permissions

Finish Synchronization


Program Versioning

Application versioning can be controlled by using the application .Net assembly version, or by setting the version manually.

When using the .Net Assembly Version, the .Net Framework Assembly:Version attribute determines the version of the client application, and is used in determining which updates can be applied. For most .Net applications, this is the best choice for versioning.

When using manual versioning, the Update Controller Version property determines the client version. This method is used for updating situations where updates can be applied without being required to rebuild the main application executable.

Automatically set the new update version

If the .Net assembly version is used for versioning, you can link the new update version number to the assembly version of your main application executable.


Update Process Permissions

Will your updates require permissions elevation?

If the users of your software applications do not hold the permissions necessary to replace your application files during an update, you can elevate the update process permissions using either the User Account Control (UAC) or by using the AppLife Update Windows Service.

If you plan to use the Windows Service, you can register your application on your development computer by using the Register your program for elevation button. Your application must be registered in order to use the service for permissions elevation.


Finish Synchronization

Information about the new AppLife Update project must be included in your application source code. This information can be transferred using the Windows Clipboard.

If your application is not forms based, or you would prefer to create and instantiate the Update Controller in code, you can paste a code snippet in either C#, VB.net, or XAML.

The properties that are synchronized are:

1. Application ID
A globally unique identifier (GUID) that uniquely identifies your application. The ID of an update package must match the application ID set in the Update Controller to be applied.

2. Public Key Token
An AppLife Update project file (aup) contains an RSA public-private key pair. When an update is built, the resulting update package is signed using the private key. When the Update Controller embedded in your application downloads an update package, it uses the signature and the public key token to verify that the package was built by its corresponding project file. It is important that you back up your project file (aup). If your project file is lost, you will not be able to build updates for your application.

3. Update Location
The update location is where the Update Controller will look to find updates for your application.


Project Properties

More:

Update Window Tab

Publishing Tab

Security Tab

Localization Tab

Custom Actions Tab

Build Tab

General Tab


Update Window Tab

Window Style

Specifies the update window shown as the AppLife Update Engine executes an update.

Update Window Customizations

Window title

Action List Current Replaces the default “AppLife Update” text on the update form displayed on the client during the execution of an AppLife Update action list update.

Image

A 48 pixel by 48 pixel image that can be adorned on the update form displayed on the client during the execution of an AppLife Update action list. By default, there is no image present.

Replacement Window

The update engine window can be completely replaced with your own customized update window. This can be accomplished by implementing the ICustomUI interface and importing the assembly that contains a class that implements that interface.


Publishing Tab

Updates can be built and published to one or more update locations. The locations can be configured from this tab.

Each location requires a URL to publish updates to. The location can be given a name and credentials.

Verify the Update Location

The defined update location can be verified using the Verify button. Verification will ensure that the location exists, and prompt to create it if it doesn’t. A test file is then published to the location, verifying the ability to publish.


Security Tab

From the security tab, the public key can be viewed and copied. If UAC elevation is being utilized, the software update launcher can be exported so that it can be code-signed with your organization’s x509 code signing certificate. Once code signed, your organization is identified as the publisher of the update package when the update process is elevated by the UAC.


Localization Tab

Localized resources can be included in built update packages. The update engine user interface has been localized to the listed geographical locales. By selecting one or more of the localized regions, the string resources for those regions will be added to updates as they are built.

Summary Text and Update Window title can also be defined individually for each selected locale.


Custom Actions Tab

The list of referenced custom action assemblies are viewed on this tab. Additional custom action assemblies can be added as well.


Build Tab

Update Version Linking

Define a local file whose assembly version or file version determines the update version as updates are created.

Update Action Paths

Defines the base directory for actions that support relative local file paths. The default base directory is the location of the aup project file.

Pre-Build Script

Defines a batch file that is executed prior to initiating an update build.

Post-Build Script

Defines a batch file that is executed after an update build is completed.


General Tab

Application name

The friendly name of this application.

Application ID

The globally unique identify for this application (GUID). The Application ID of the Update Controller within your application must match this value.

Summary if no updates are available

The text that is displayed to a client user when an update is not found. By default, no summary information is displayed. This text can be localized for each selected language.


The Make Update Window

The Make Update Window allows you to add and configure actions that will be built into your next update. There are three panels within the Make Update Window. The Actions Palette, the Action list, and the Action Editor panel.

Adding an Action

You can select an action from the Action Palette by clicking on an action or drag and drop onto the Actions list. When you click an action, the action is added to the Action list below the currently selected action in the list.

Manipulating Actions in the list

Actions in the list can be selected individually or in a multi-action selection.

Actions in the list can be dragged and dropped up and down the list. The action list toolbar has Up/Down command buttons. The Up/Down command buttons are enabled when the selected action(s) are contiguous.

Actions can be cut/copied/pasted individually or as a multi-action selection. When actions are pasted, they are added below the currently selected action in the list.

Actions can be deleted individually or as a multi-action selection. You are prompted before an action is deleted.

Actions can be checked for inclusion in the built update or unchecked for exclusion. Actions that are excluded are not included in the build process. They are treated as if they do not exist in the update.

Valid Action Indication

Whether an action in the list is valid or not is visually indicated in the Action list.

The icon displayed included a tooltip to indicate what validation rule is currently broken. The update cannot be built until all the actions in the list are valid.

Editing Individual Actions

Actions are configured through the Action Editor. When an action is selected in the Action list, its editor is placed in the Action Editor panel for configuration. Custom actions use a property grid for editing their properties. You can implement your own editors for your custom actions.


Action Conditional Expression Dialog

The Action Conditional Dialog provides the ability to test an Update Action conditional expression by defining test values of Shared Properties within the expression.

Any Shared Property utilized in the Conditional Statement is included in the grid, allowing you the ability to set a test value.

The Test button assigns the values specified in the grid to the Shared Properties in the expression, and then evaluates the expression showing the test results in the results label.

See Action Conditionals for more information.


Register Assembly Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client that contains the .net dll.

Subdirectories – The directory below the designated client root folder that contains the .net dll that is to be registered.

The target client folder and subdirectory values can be substituted into the Execute and Rollback command lines using the <path> variable.

Execute command line – The Regasm.exe command line to execute during the update execute stage.

Rollback command line – The Regasm.exe command line to execute in the event of a rollback.

Expansion variables can be used to set the target client subdirectory property, Execute, and Rollback command lines.

See the Register Assembly action for more information.


Register Library Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client that contains the dll or ocx file.

Subdirectories – The directory below the designated client root folder that contains the dll or ocx that is to be registered.

Library to register – The name of the dll or ocx file.

Use DllRegisterServer/DllUnregisterServer, Use DllInstall, DllInstall command line, Supress dialogs – Parameters to the Regsrvr32 call. See msdn for more information.

Expansion variables can be used to set the target client subdiretory property, Library to register name and the DllInstall command line.

See the Register Library action for more information.


Unregister Library Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client that contains the dll or ocx file.

Subdirectories – The directory below the designated client root folder that contains the dll or ocx that is to be registered.

Library to register – The name of the dll or ocx file.

Use DllRegisterServer/DllUnregisterServer, Use DllInstall, DllInstall command line, Supress dialogs – Parameters to the Regsrvr32 call. See msdn for more information.

Expansion variables can be used to set the target client subdirectory property, Library to unregister name and the DllInstall command line.

See the Unregister Library action for more information.


Add & Replace Files Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to place the files in the file list.

Subdirectories – The directory below the designated client root folder to place the files in the file list.

Files to place in this folder – A collection of files that are to be added or replaced on the client in the defined folder. Files that are added to the list must be present for the action to be valid.

See the Add & Replace files action for more information.


Add Files By Comparison Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to place files that are newer or does not exist in the baseline folder and all previous updates.

Subdirectories – The directory below the designated client root folder to place the files.

Baseline folder – The folder that is compared to the Current version folder to determine files that should be added to the update.

Current version folder – The folder that represents the current version of your software. The client folder will mirror this folder after the update is completed.

Files to ignore in the current folder – Wildcard exclusion filter. This property allows you to exclude files from the update whose name matches your defined wildcard filter. Multiple filters can be applied, delimited by a semicolon. (*.config; *.pdb)

Include subdirectories – Checked to indicate that the analysis should include all subassemblies within the current version folder.

The files that are included in the update is determined during the update build. The output window identifies the action taken for each file in the Current version folder.

Expansion variables can be used to set the target client subdirectory property.

See Add & Replace Files by Comparison action for more information.

More:

Add Files by Comparison (v4.0 Change)


Add Files by Comparison (v4.0 Change)

The algorithm used to identify files to include in an update using the Add & Replace files by Comparison action has been changed in version 4.0. In earlier versions of AppLife Update, an update build folder and data identifying which updates were published in the single update project publish location were maintained by the AppLife Update project file (aup). This information, along with the target version list of the update being built were used to add or remove files from the file list based on a determination that a file must already be on a deployed client targeted by the new update. This analysis allowed for a proper file inclusion list, even when the action baseline folder didn’t match the new update’s lowest target version.

In version 4.0, the project build folder and update location data has been removed from the update project in order to support publishing updates to multiple independent update locations. This change affects the Add & Replace files by Comparison algorithm because this project information was used to determine the files list. Because of this, the action has been simplified to compare files between the designated baseline and current folders, without regard to update version information. For an accurate file list, the designated baseline folder contents needs to represent the lowest target version of the update being built.

Clicking the Update button will upgrade the action to use the replacement action.


Delete Files Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to place files that contains the file(s) you are removing.

Subdirectories – The directory below the designated client root folder that contains the files.

Files to delete – The filename of the files that will be deleted. One file per line. The filename can use * and ? wildcard characters. Case is not considered.

Expansion variables can be used to set the target client subdirectory property.

See Delete Files action for more information.


Masked Add & Replace Files Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to place files that contains the file(s) you are adding/replacing.

Subdirectories – The directory below the designated client root folder that contains the files.

Folder to copy files from – The local folder that contains the files that the mask is applied to.

Mask to use when copying files – The file mask that determines the files that will be included.

The files that match the mask are written to the output window during the build process.

Expansion variables can be used to set the target client subdirectory property.

See the Masked add & replace files action for more information.


Patch Folder Action Editor

Condition – Use Shared Properties as variables to conditionally execute this action during an update.

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Client folder – The folder on the deployed client where the files to be patched exists.

Subdirectories – The directory below the designated client root folder that contains the files.

Base folder: The folder on the build machine that includes the baseline file versions. This folder should represent the deployed client folder.

Target folder: The folder on the build machine that includes the target files. As the update is built, files in the target folder are compared with their counterpart in the base folder. If a different version exists in the base folder, a differential patch is created and added to the update. If the file doesn’t exist in the base folder, the whole file is added to the update.

The Patch Folder action utilizes the Microsoft Delta Compression API to create a differential patch file between two versions of an assembly during an update build, and then packages the patch file into the update.

As the update is executed, this differential patch is combined with the base file that exists on a deployed client to construct the target file.

Utilizing the Patch Folder action can significantly reduce the size of the resulting update package. The specific version of the baseline files must be present on the system being updated.

NOTE: The Windows Installer SDK must be present on the system building the update package. Get it here. Patch extraction support is available on all Windows versions later than Windows 2000.

See Patch Folder Action for more details


Patch Existing File Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to place files that contains the file(s) you are adding/replacing.

Subdirectories – The directory below the designated client root folder that contains the files.

Version Information displays the assembly version and file version of the baseline file and the target file.

The Patch Existing File action utilizes the Microsoft Delta Compression API to create a differential patch file between two versions of an assembly during an update build, and then packages the patch file into the update.

As the update is executed, this differential patch is combined with the base file that exists on a deployed client to construct the target file.

Utilizing the Patch Existing File action can significantly reduce the size of the resulting update package. The specific version of the baseline file must be present on the system being updated.

NOTE: The Windows Installer SDK must be present on the system building the update package. Get it here. Patch extraction support is available on Windows 2000 and later.

See File Patching Action for more details


Replace Files on Restart Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to place files that contains the file(s) you are adding/replacing.

Subdirectories – The directory below the designated client root folder that contains the files.

Files to place in this folder – A collection of files that are to be added or replaced on the client in the defined folder. Files that are added to the list must be present for the action to be valid.

Selected file – The file path of the selected file. Paths can be modified. Paths relative to the aup project file location is supported.

Prevent the application from restarting – If the file to be replaced on restart would prevent your application from successfully restarting after the update completes, or your update will request a restart of the operating system, check this box.

See the Replace files on restart action for more details.


Create Folder Action Editor

Condition – Use Shared Properties as variables to conditionally execute this action during an update.

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to create the new folder within.

Subdirectories – The directory below the designated client root folder to create a new folder. This action will create multiple folder levels in one step.

See Create Folder Action for more information.


Delete Folder Action

Condition – Use Shared Properties as variables to conditionally execute this action during an update.

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target folder to delete – The folder on the client to delete during the update.

Subdirectories – The directory below the designated client root folder to delete.

Only delete if the folder is empty – When selected, the action will not delete any folder contents and will error if the designated folder is not empty.

Delete all files and subdirectories – When selected, the action will delete any content within the designated folder.

Abort the update if the deletion fails – When selected the update will fail and rollback if any deletion fails.

See Delete Folder for more information.


Copy Folder Contents Action Editor

Condition – Use Shared Properties as variables to conditionally execute this action during an update.

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to copy content into.

Subdirectories – The directory below the designated client root folder to copy content into.

Folder to copy files from – The folder on the build machine from which to add files to the update.

Include subdirectories – When checked, any subdirectories within the folder to copy files from will also be included. Subdirectory folders will be created automatically on the deployed client as the action executes.

See Add Folder Contents Action for more information.


Create File Shortcut Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Shortcut location – The disk location on the client to place the shortcut. This includes the name of the shortcut. Select the known folder on the client, then provide sub path and shortcut name. If this location does not end with an .lnk extension, it will be appended automatically.

If an existing shortcut is found – Identify what action should be taken if an identically named shortcut already exists in the defined location.

· Replace the existing shortcut (default)

· Skip the action and leave the existing shortcut

· Abort the update

Shortcut target – The disk location of the file that the shortcut is going to operate on. Select the known folder on the client, and then provide any sub path and the file name.

Command-line arguments – Add any arguments that are required to be passed to the shortcut target when this shortcut is executed.

Start in – Specify a path to set the start path property of the shortcut. Select the known folder on the client and specify any sub path information.

Run – Specify the mode that the target should launch in. Choices are:

· Normal window (default)

· Maximized

· Minimized

Comment – Specify the comment property of the shortcut. This value results in a shortcut tooltip.

Icon source – Specifies an assembly that contains an icon that can be displayed with the shortcut. Select the known folder on client, any sub path information, and the name of the assembly. Define the index of the icon within this assembly with the Index property. To use the default icon, set this property to Explicit Path.

Index – The index within the identified Icon source of the icon that is to be used with this shortcut.

See Create File Shortcut for more information.


Install .NET 4.x Action Editor

Condition – Use Shared Properties as variables to conditionally execute this action during an update.

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Installer options – Identify which installer to use. The .Net Framework can be installed using a small bootstrapping installer that downloads necessary framework components from the Microsoft site. Alternatively an installer that includes all framework components can be used.

User interface – Identifies how the AppLife Update process will interact with the user during the framework installation. The framework installer user experience can be shown, or progress can be ticked within the AppLife Update user interface.

Important – If you utilize the AppLife Update Windows Service for permissions elevation, you must use the Show progress as part of the update option. This is because the serviced update process cannot interact with the user outside of the AppLife Update user interface.

If a restart is required, prompt the user to restart – Check this option if the update process should provide the user an option to defer a system restart, if one is necessary. If this option is not checked, and a system restart is necessary, the restart will occur as the update completes.

Restart message – Customize the message displayed to a user if a restart is necessary.

Store a value indicating whether a restart is required as a Shared Property – Identify a Shared Property to indicate a restart is necessary. A Shared Property can be used to conditionally perform follow up actions, such as preventing your host application from restarting.

See Install .NET 4.0 Framework action for more information.


Install GAC Assembly Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client to place the assembly for GAC registration.

Subdirectories – The directory below the designated client root folder to place the assembly.

Assembly to Install – The location on the build system where the assembly to be placed in the client GAC resides.

Reference Type – The reference counting scheme to employ in maintaining the assembly in the GAC.


Uninstall GAC Assembly Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Assembly to Install – The location on the build system where the assembly to be placed in the client GAC resides. The fully qualified assembly name is imported.

Reference Type – The reference counting scheme employed in maintaining the assembly in the GAC.


Execute Msi Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client that contains the Windows Installer(msi) to execute.

Subdirectories – The directory below the designated client root folder that contains the msi to execute.

The target client folder and subdirectory values can be substituted into the Execute and Rollback command lines using the <path> variable.

Execute command line – The msiexec.exe command line to execute during the update execute stage.

Rollback command line – The msiexec.exe command line to execute in the event of a rollback.

Action to take if the MSI fails – Determines whether to continue the update if this msi fails, or abort.

Store Exit Code – When selected, stores the MsiExec process Exit Code into the designated Shared Property.

Expansion variables can be used to set the target client subdirectory property, Execute, and Rollback command lines.

See the Execute Msi action for more information.


Restart Operating System Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Allow the user to decide whether to restart – When checked, this action will prompt the user with the message specified for confirmation of restart.

Display this message – Specify the optional message to display to the user.

Abort the update if restart will not occur – If the user chose not to restart the operating system, this setting determines whether the update will proceed or be aborted.

See the Restart Operating System action for more information.


Run Command Line Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

<path1> variable – The folder on the client that is assigned to command line variable <path1>.

<path2> variable – The folder on the client that is assigned to command line variable <path2>.

The target client folder and subdirectory values can be substituted into the Execute and Rollback command lines using the <path1> and <path2> variable.

Execute command line – The command line to execute during the update execute stage.

Rollback command line – The command line to execute in the event of a rollback.

Expansion variables can be used to set the target client subdirectory property, Execute, and Rollback command lines.

See the Run Command Line action for more information.


Create Registry Key Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Key to create – Defines the registry hive to create the key in. This value, combined with the specific key property locates the new key in the registry.

Type to specify a key – The sub path under the defined hive to create the key. The entire key path is created. The initial \ in the path can be omitted or not.

Ex: \MyKeys\Key1

MyKeys\Key1

Expansion variables can be used to set the key to create sub path.

See Create Registry Key for more information


Delete Registry Key Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Key – Defines the registry hive where the key is located.

Type to specify the key – The sub path under the defined hive where the key is located. The initial \ in the path can be omitted or not.

Ex: \MyKeys\Key1

MyKeys\Key1

Note: This action will not delete a key with sub keys. You must delete each sub key in the branch individually.

Expansion variables can be used to set the key sub path.

See Delete Registry Key for more information.


Delete Registry Values Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Key – Defines the registry hive where the key is located.

Type to specify the key – The sub path under the defined hive where the key is located. The initial \ in the path can be omitted or not.

Ex: \MyKeys\Key1

MyKeys\Key1

Values to delete – A list of individual values within the key to remove. Place one value per line.

Expansion variables can be used to set the key to create sub path, and each value to delete.

See Delete Registry Values for more information.


Set Registry Values Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Key – Defines the registry hive where the key is located.

Type to specify the key – The sub path under the defined hive where the key is located. The initial \ in the path can be omitted or not.

Ex: \MyKeys\Key1

MyKeys\Key1

Name – The name of the value to be set. The value will be either created or replaced.

Type – Enter the specific type of registry value that should be used.

Value – Enter the value of the registry key value. The value format is dependent on the type specified.

Binary – Binary data in any format. The value is entered in two character hexadecimal sets separated by a space. Each set represents 8 bits.

DWord – 32 bit number, entered in decimal base

Qword – 64 bit number, entered in decimal base.

Multi-String – A sequence of null terminated strings.

Expandable string - A null-terminated string that contains unexpanded references to environment variables.

Expansion variables can be used to set the key sub path, each new registry value name, and each new registry value.

See Set Registry Values for more information.


Read Registry Value Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Key – Defines the registry hive where the key is located.

Type to specify the key – The sub path under the defined hive where the key is located. The initial \ in the path can be omitted or not.

Ex: \MyKeys\Key1

MyKeys\Key1

Value to read – The value within the registry key to read.

Shared property to read into – Specify the key name of the Shared Property to place the value read. Exclude the enclosing $’s when defining the shared key name.

Action to take if the value can’t be read – You can define a default value if the registry value can’t be read, or you can choose to abort the update.

Expansion variables can be used to set the key sub path, the value to read, the Shared property key name to read into, and the default value if the key value can’t be read.

See Red Registry Value for more information.


Start Service Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Service to start – The name of the service. The name must be defined for this action to be valid.

You can easily locate the service name of any services on your computer by using the Computer Manager Services list. From any service, view the properties and the service name is listed.

Force the service to restart if already running – When this action is executed, no action is taken if the defined service is already running. If you want to force a restart in this situation, check this box.

Timeout (Seconds) – The time in seconds the action should wait for the service to stop before aborting or continuing.

Action to take if the action times out – When the action times out, the update is either aborted or allowed to continue.

Arguments – List of arguments that are passed to the defined service when the start command is executed. Enter one argument per line.

Expansion variables can be used to set the service name of the service to start and each service argument.

See Start Service for more information.


Stop Service Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Service to stop – The name of the service. The name must be defined for this action to be valid.

Timeout (Seconds) – The time in seconds the action should wait for the service to stop before aborting or continuing.

Action to take if the action times out – When the action times out, the update is either aborted or allowed to continue.

You can easily locate the service name of any services on your computer by using the Computer Manager Services list. From any service, view the properties and the service name is listed.

Expansion variables can be used to set the service name of the service to stop.

See Stop Service for more information.


Replace Public Key Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

New public key – The public key value that will replace the current public key on the client.

See Replace Public Key Action for more information.


Add Xml Attribute Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client where the xml file that is to be edited is located.

Subdirectories – The directory below the designated client root folder to find the xml file that is to be edited.

XML file to edit – The name of the xml file that is to be edited.

XPath query to select the element into which to add the attribute – Use an XPath expression to identify the node within the xml file that you want to add an attribute to.

New attribute name and value – Type the name and value of the new Xml Attribute that you want to add.

If multiple elements are found – Identify the action that you want to occur in the event that multiple xml elements are returned by your XPath expression. You can choose to:

· Add the attribute to all nodes

· Add only to the first node

· Add only to the last node

· Don’t add any attributes

· Abort the update.

Expansion variables can be used to set target client subdirectory, file name of the xml file to edit, Xpath query, attribute name, and attribute value.

See Add Attribute for more information.


Add Xml Element Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client where the xml file that is to be edited is located.

Subdirectories – The directory below the designated client root folder to find the xml file that is to be edited.

XML file to edit – The name of the xml file that is to be edited.

XPath query to select the element into which to add the attribute – Use an XPath expression to identify the node within the xml file that you want to add an element to.

New element name and value – Type the name and value of the new Xml Element that you want to add.

If one or more matching elements is found – In the event that one or more elements are found that match the element that is being added, you can choose to:

· Insert the new element, ignoring any existing ones

· Delete any existing elements and then insert the new one

· Do not insert an element

· Abort the update.

If multiple parent elements are found – Identify the action that you want to occur in the event that multiple xml elements are returned by your XPath expression. You can choose to:

· Add the element to all nodes

· Add only to the first node

· Add only to the last node

· Don’t add any elements

· Abort the update.

Expansion variables can be used to set target client subdirectory, file name of the xml file to edit, Xpath query, new element name, and new element value.

See Add Xml Element for more information.


Change Xml Node Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client where the xml file that is to be edited is located.

Subdirectories – The directory below the designated client root folder to find the xml file that is to be edited.

XML file to edit – The name of the xml file that is to be edited.

XPath query to select the node to be changed – Use an XPath expression to identify the node within the xml file that you want to change.

New node text – Type the new text of the Xml Node.

If multiple nodes are found – Identify the action that you want to occur in the event that multiple xml nodes are returned by your XPath expression. You can choose to:

· Change all nodes

· Change only to the first node

· Change only to the last node

· Don’t change any attributes

· Abort the update.

Expansion variables can be used to set target client subdirectory, file name of the xml file to edit, Xpath query, and new node text.

See Change Xml Node for more information.


Delete Xml Node Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client where the xml file that is to be edited is located.

Subdirectories – The directory below the designated client root folder to find the xml file that is to be edited.

XML file to edit – The name of the xml file that is to be edited.

XPath query to select the node to be deleted – Use an XPath expression to identify the node within the xml file that you want to delete.

If multiple nodes are found – Identify the action that you want to occur in the event that multiple xml nodes are returned by your XPath expression. You can choose to:

· Delete all nodes

· Delete only to the first node

· Delete only to the last node

· Don’t delete any nodes

· Abort the update.

Expansion variables can be used to set target client subdirectory, file name of the xml file to edit, and Xpath query.

See Delete Xml Node for more information.


Read Xml Node Text Action Editor

Action description – Descriptive text that can be used to identify this particular action in the Actions list.

Target client folder – The folder on the client where the xml file that is to be edited is located.

Subdirectories – The directory below the designated client root folder to find the xml file that is to be edited.

XML file to read – The name of the xml file that is to be read.

XPath query to select the node to be read – Use an XPath expression to identify the node within the xml file that you want to read.

Shared property to read into – Type the key name of the Shared Property entry that the value should be set to.

If multiple nodes are found – In the event that one or more elements are found that match the element to be read, you can choose to:

· Read the first node found

· Read the last node found

· Use a default value

· Abort the update.

If the value can’t be read – Identify the action that you want to occur in the event that the value can’t be read from the xml document. You can choose to:

· Use a default value

· Abort the update.

Expansion variables can be used to set target client subdirectory, file name of the xml file to read, Xpath query, shared property name, and default value.

See Read Xml Node for more information.


Comment Action Editor

Action description – Descriptive text that can be used to comment the action list actions.

This action perform no work in an update.


Run Action List Editor

Action description – Descriptive text that can be used to comment the action list actions.

Action list to run – Defines the name of the action list within the current project to run.

See Run Action List action for more information.


Dynamic Code Action

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Language: Select C# or Visual Basic.Net (The default language can be set in the application options dialog)

Build – Test builds the source code provided.

Enable Debugging – Builds the resulting dynamic custom actions assembly in debug mode and includes debug symbols in the update. This setting is global for all Dynamic code actions in the project.

Framework- Designates the .Net Framework to target. Note: The build system must have the .Net Framework 3.5 SP1 or higher to designate a target framework.

References – Provides a dialog to reference additional .Net assemblies for use in the dynamic action source code.

The Dynamic Code Action provides the ability to create custom update activity using .Net source code. The defined source code is compiled and packaged into the update as Make Update builds the update.

Through the UpdateContext object, the Shared Properties collection can be manipulated within a Dynamic Code Action.

Shared Properties can be used in other actions as well as within Action Conditional expressions.

Progress and textual information can be sent to the Update Engine user interface for user presentation by using the OnProgressChanged method from within an update action method body.

OnProgressChanged(new UpdateProgressChangedEventArgs(10, "Dynamic code action progress comments"));

See the AppLife Update API Documentation content for Kjs.AppLife.Update.Engine.Core UpdateAction class for more detailed technical information. The API documentation can be accessed from the Help menu within Make Update.


Prevent Application Restart Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

This action will prevent the host application from restarting after the update completes, regardless of the restart behavior specified by the Update Controller configuration.


Begin Transaction Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Transaction Name – Name of the transaction that is started by this action. Use this name to configure the other database actions to use the transacted begun by this action.

Isolation Level – Configure the appropriate database isolation level for this transaction. Choices include Chaos, Read Committed, Read Uncommitted, Repeatable Read, Serializable, Snapshot.

Data Provider – You can set the data provider of this transaction directly, read the provider from configuration appSettings, or read from configuration connectionStrings. Any data provider can be set. The data provider must already be installed on the target client systems.

Connection String – You can set the connection string for this transaction directly, read the connection string from configuration appSettings, or read from configuration connectionStrings.

Configuration file location – If either the data provider or the connection string is to be read from a configuration file, you define the location of the config file. Pick the client folder and define the required sub-path.

Configuration file name – The name of the configuration file to use.

Expansion variables can be used to set the Data Provider, Connection String, Configuration file sub path, and Configuration Name.

See Begin Database Transaction for more information


Commit Transaction Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Transaction Name – Name of the transaction that is committed by this action. This name should match the name defined on the corresponding Begin Database Transaction Action.

See Commit Database Transaction for more information.


Transacted Query Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Transaction Name – Name of the transaction that this action should use. This name should match the name defined on the corresponding Begin Database Transaction Action.

Specify the query directly – Allows you to directly enter the query text to be executed on the database.

Load the query from a file when the project is built – Reads the query text from a designated file during the update build process.

Store first result in shared property – Allows you to read information from a database and share the information with other actions through Shared Properties and Expansion variables.

Expansion variables can be used to set the Query Text and when defining a shared property name to store the first result in.


Transacted Stored Procedure Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Transaction Name – Name of the transaction that this action should use. This name should match the name defined on the corresponding Begin Database Transaction Action.

Stored Procedure Name – Enter the name of the Stored Procedure that this action should execute.

Parameters Collection

Define the stored procedures parameters by adding rows to the parameters grid.

· Name Column
Enter the name of the parameter

· Type
Select the parameter type

· Value
Enter the value of the parameter

· Null
Check to indicate the parameter is null

· Size
The size of the parameter

· Direction
Define the direction of the parameter

· Output Property
A Shared Property key to copy the parameter value to upon execution completion.

Store first result in shared property – Allows you to read information from a database and share the information with other actions through Shared Properties and Expansion variables.

Expansion variables can be used to set the stored procedure name, parameter names, parameter values, and parameter output properties.

See Transacted Stored Procedure for more information.


Backup SQL Server Database Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Connection to use – The key name of the SQL Connection to use, as defined in.

See Backup SQL Server Database for more information.


Begin SQL Server Transaction Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Store the transaction – Defines the Shared Property key value that will hold this transaction.

Isolation level – Choose the SQL Transaction isolation level that this transaction will use.

See Begin SQL Server Transaction Action for more information.


Close SQL Server Connection Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Connection Shared Property Key – The connection to close.

See Close SQL Server Connection Action for more information.


Commit SQL Server Transaction Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Transaction Shared Property Key – The transaction to commit.

See Commit SQL Server Transaction Action for more information.


Open SQL Server Connection Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Shared property to store the connection – The key value used to when the new connection is placed into the Update Context Shared Properties collection. This is the key used by other actions in the update to access this connection.

Connection string – Select to define the connection string using a config file Connection Strings collection, a config file appSettings element, or by setting directly.

Connection string name / Connection string – The key value used to look up the connection string, or the string value of the connection string. When setting directly, other shared property values are typically used. Shared properties can be expanded by using the $ notation. (e.g. $MyConnStr$)

Place the database in single-user mode – When checked, the database connection is opened for exclusive access. Any pending database transactions can be cancelled immediately, or the connection will wait for a specified period of time for all ongoing transactions to close.

Configuration file location – Identify the path and name of the config file that holds your connection string information. This information is only necessary when configured to retrieve a connection string from the Connection Strings or appSetttings area of a config file.

See Open SQL Server Connection action for more information.


Run SQL Server Query Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Shared property key – The Shared Property key of either a SQL Connection or SQL Transaction object that will be used to run the SQL query.

Query – The SQL query can be defined directly or by specifying a sql file. If a sql file is used, the file must be present on the build machine, at the time that an update is created. If a direct value is used, the sql text can be entered directly, or specified using a Shared Property. If a shared property is used, the value must contain the SQL text.

Timeout – Specifies the time to wait for the query to complete.

Store the last query result in a shared property – When checked, the output of the last sql statement will be added to the Update Context Shared Properties collection using the key value specified.

See the Run SQL Server Query Action for more information.


Set Shared Property Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Shared property to set – The key name of the Shared Property that this action will set the value of.

Value type – Defines the type of value to set the shared property to.

· Text – Allows you to type the string value of the shared property in the New Value textbox

· Blank – Sets the value of the defined shared property to an empty string

· Update Version – Sets the value of the shared property to the Update Version value of this update

· Directory – Lets you choose from a list of directory paths to set into the defined shared property. This list includes among others, the Application Directory.

· Processor type – Sets the value to either “32” or “64”, based on the whether the operating system is 32 or 64 bit.

New Value – The value to set the Shared Property to.

Expansion variables can be used to set the Shared Property name and the New value property.

See Set Shared Property for more information.


Check Service Exists Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Service name to check – The name of the service. This can be viewed in the Service Properties view.

Shared property to read into – The name (or key) of the Shared Property that will hold the results of the check. The Shared Property will hold a string of value “True” if the service exists, or “False” if the service does not exist.


Check File Exists Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Client folder – The folder on the client where to find the file of interest. See Files & Folders for more information.

Subdirectories – Additional path information, relative to the designated client folder.

Check if file exists – The file name to check for. The file is checked only in the designated folder.

Shard property to read into - The name (or key) of the Shared Property that will hold the results of the check. The Shared Property will hold a string of value “True” if the file exists, or “False” if the file does not exist.

Note: Shared Properties are expanded in all of the action properties.


Check Folder Exists Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Client folder – The folder on the client to that is to be checked for existence. See Files & Folders for more information.

Subdirectories – Additional path information, relative to the designated client folder.

Shard property to read into - The name (or key) of the Shared Property that will hold the results of the check. The Shared Property will hold a string of value “True” if the file exists, or “False” if the file does not exist.

Note: Shared Properties are expanded in all the action properties.


Read File Version Action Editor

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Client folder – The folder on the client to find the target file. See Files & Folders for more information.

File to read version from – The file or assembly name.

Version Type- Defines whether to read the .Net Assembly Version or the File Version.

Shard property to read into - The name (or key) of the Shared Property that will hold the results of the action. The Shared Property will hold a string value that represents the discovered version number.

Action to take if the value can’t be read – If the version stamp of the designated file cannot be read, a default value can be used or the update can be aborted.

Default value – A designated value that can be read into the Shared Property if the file cannot be read.

Note: Shared Properties are expanded in all of the text-based action properties.


Set Display Version Action Editor

Updates the Display Version of an installed application to match the version of the update being applied, as displayed in the Windows Programs and Features lists.

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Msi Product ID or Application Name – The Product ID or Application Name. This value is used to identify the correct Display Version to update.

Abort the update if the setting display version fails – When checked, if the display version could not be updated, the update will fail and rollback.

Note: Msi Product ID or Application name supports expanding Shared Properties.


AppLife Manager Set Update Version Action Editor

This action will update the AppLife Manager version stamp for the designated application. See AppLife Manager Version Number for more information.

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Version Source – Sets the source of the version string that will be placed in the AppLife Manager configuration settings.

Use active update version – The version number of the executing update will be placed in the configuration file.

Set explicit version value – Uses the value set tin the Explicit version value textbox.

Explicit version value – When the Version Source is set to use explicit version, this value is used. Shared properties used in this value are expanded during execution.

See Determine the Currently Installed Version for more information.


AppLife Manager Find Install Directory Action Editor

This action will search for a designated assembly (or file) and then write the Directory Information of the discovered file into the AppLife Manager application configuration. See Application Directory for more information.

Action Description - Descriptive text that can be used to identify this particular action in the Actions list.

Assembly to search for – The file name or assembly name to search for. This is a file that would be located in the targeted application directory, or a directory that would be relative to the target application directory.

Search Install Folders – When checked, the action will search Program Files and Common Program Files for the target assembly. The 32-bit (x86) directories will be searched first on 64 bit operating systems.

Search additional folder – A custom directory that will be searched for the target assembly. Windows Environment Variables can be used in this value.

Recursive – When checked, all inner directories of the designated additional search folder will be searched.

Action to take if assembly can’t be found – The designated default value can be used or the update can be terminated and rolled back.

Default value – The value to use if the designated assembly cannot be found and the action to take is set to Use default value. Shared Properties and Windows Environment Variables are expanded when used in this value.

Shared property to read File Location into - The name (or key) of the Shared Property that will hold the results of the action. The Shared Property will hold a string value that represents the complete location path to the targeted assembly, including the assembly name.

Shared property to read Directory Name into - The name (or key) of the Shared Property that will hold the results of the action. The Shared Property will hold a string value that represents only the directory path of the targeted assembly. If the default value was used, this value will be read into the Shared Property.


Missing Action Place Holder

The placeholder maintains the state information of a custom action that is missing. Once the missing assembly is located, the action will be refreshed.

Action type – Displays the name of the missing action type.

Assembly – Displays the Assembly Name of the missing assembly.

To manually locate the missing assembly, click the Locate the action’s assembly… button. You can browse to the location of the assembly.


License Form

The license form allows you to enter your purchased license number. AppLife Update will operate in trial mode for 30 days after installation, after which the build functions will cease to operate until the software is properly licensed.

Your current license number is displayed on this form.

You can purchase a license by clicking on the “Get a license number” button.

To enter or replace a license number, type or paste your license number into the New license number text box and click OK.

See License Management for more information..


Options Form

More:

Preferences

Proxy

Spelling


Preferences

Reset “Don’t show this information again” help dialogs

Clears all help dialogs and displays them again when appropriate.

Clear recent files menu

Clears the list of recent projects from both the start page and the file menu.

Always warn before rebuilding an existing update

Check this box if you always want to be warned before building an update over an existing update. If unchecked, you can re-build the highest version number for 24 hours past its original build time without being warned. are only warned before re-building the highest version 24 hours after its previous build time.

Check for updates at startup

When checked, AppLife Make Update will check for available updates for AppLife Update.

Automatically re-open the last project at startup

When checked, Make Update will store the location of the most recently opened project file and attempt to re-open the project as the Make Update application is launched.

Default language for dynamic actions

The Dynamic Action update action that is located in the Update actions palette provides functionality to use C# or Visual Base.net to create customized updating activity. Set this value to specify the default language for this action.


Proxy

Automatically detect proxy settings – Check this box to configure Make Update to automatically detect proxy settings and use those settings to publish update projects.

Note: Ftp publishing through an http proxy server is not supported. In this scenario, you must use http publishing or bypass your proxy server for ftp.

Proxy address – Manually set the address of your proxy server here. The address is expecting a fully qualified URI identifying the location of your proxy.

Ex: http://kjsproxy.kineticjump.com:8080/

Check the Bypass proxy server for local addresses box to ignore the proxy setting for local addresses.

Check the Use default credentials to send the credentials that you are currently logged in under to the proxy server for authentication when publishing updates.

To set proxy specific credentials to the proxy server, uncheck the Use default credentials box and enter a user name, password and domain into the appropriate text boxes.


Spelling

Enable / disable spell checking by setting the checkbox.

Add words to the custom dictionary by typing into the textbox and clicking on the Add command.

Remove words from the custom dictionary by selecting the word to remove and clicking the Remove command.


Automating AppLife Update

More:

Command Line Utility

MSBuild Task

FinalBuilder Action


Getting Started

More:

Installation

Quick Starts

License Management


Action Editor

A panel within the Current update tab that allows you to modify the properties of the currently selected action in the Action list.


Action List

A list of actions in the project that define how your next update will behave.


Action Palette

The panel in the Current update tab that allows users to add update actions to their projects.


AppLife Update action list

A type of update that uses defined actions to execute an update on clients. The action list update process executes a three stage update process.


Assembly Version Number

The version number of the hosting application. This is set using the [assembly] attribute. (i.e [assembly: AssemblyVersion("1.0.0.0")])


aup

The extension of an AppLife Update project file created using the AppLife Make Update application. Aup project files can be used by the AppLife Update command line utility to build and publish updates.


Client

A computer running your deployed software that contains an AppLife Update Controller. Updates are applied to clients.


Current update

The update that has not yet been built. Properties of the Current Update reflect the next update.


Custom data

A multiline text value that is transfered to the client with the rest of the Director information. Custom data is not used by AppLife Update. Implementors can use this custom data to transfer information about an update to the client. This information is availabe when an update is found.


Custom update executable

A user provided program that is executed on the client in order to perform the update process from one software version to another.


Director.Xml

The Xml file that contains meta information about the available updates within a server folder.


Historical summary

A collection of summary text values between the update version being applied and the version of software applying the update.


Make Update

The AppLife Update application that creates update project files. Make Update can build and publish AppLife Update projects.


msi

A Windows Installer database file. Used with AppLife Update, an msi performs either a major or minor upgrade of an installed product.


Msiexec.exe

A Microsoft executable that executes installations and updates of software that is defined within a Windows Installer database.


msp

A Windows Installer patch file. Used with AppLife Update, will perform a patch of an installed product


Network Folder

A network location that contains a director file and update packages for an application.


<package>

A placeholder variable that can be placed in a Windows Installer update project command line that will be replaced with the local path to the wrapped msi or msp file.


Previous update

An update that was previously built. Information about the update is included in the Director and available to clients for discovery. Previous updates are assumed to be published.


Public Key

The public part of a cryptographic key pair. Within AppLife Update, the public key is used to validate the signature of a downloaded update package before it is applied.


Shared Properies

A collection of objects held in a dictionary that is available to all actions within an update action list through the update context object.


Target Version

A version number that an update can be applied to.


Update Controller

A .Net component that extends the features of AppLife Update to .Net applications.


Update Launcher

The executable that is launched in its own process by the Update Controller. The Update Launcher is responsible for coordinating the execution of the update executable, and re-launching the application.


Windows Installer database

A file with an msi or msp extension that contains tables of information that commands the msiexec.exe how to update your software.


Glossary of Terms

More:

<package>

Action Editor

Action List

Action Palette

AppLife Update action list

Assembly Version Number

aup

Client

Current update

Custom data

Custom update executable

Director.Xml

Historical summary

Make Update

msi

Msiexec.exe

msp

Network Folder

Previous update

Public Key

Shared Properies

Target Version

Update Controller

Update Launcher

Windows Installer database


Reference

More:

New Project Wizard

Project Properties

The Make Update Window

Action Conditional Expression Dialog

Register Assembly Action Editor

Register Library Action Editor

Unregister Library Action Editor

Add & Replace Files Action Editor

Add Files By Comparison Action Editor

Delete Files Action Editor

Masked Add & Replace Files Action Editor

Patch Folder Action Editor

Patch Existing File Action Editor

Replace Files on Restart Action Editor

Create Folder Action Editor

Delete Folder Action

Copy Folder Contents Action Editor

Create File Shortcut Action Editor

Install .NET 4.x Action Editor

Install GAC Assembly Editor

Uninstall GAC Assembly Editor

Execute Msi Action Editor

Restart Operating System Action Editor

Run Command Line Action Editor

Create Registry Key Action Editor

Delete Registry Key Action Editor

Delete Registry Values Action Editor

Set Registry Values Action Editor

Read Registry Value Action Editor

Start Service Action Editor

Stop Service Action Editor

Replace Public Key Action Editor

Add Xml Attribute Action Editor

Add Xml Element Action Editor

Change Xml Node Action Editor

Delete Xml Node Action Editor

Read Xml Node Text Action Editor

Comment Action Editor

Run Action List Editor

Dynamic Code Action

Prevent Application Restart Action Editor

Begin Transaction Action Editor

Commit Transaction Action Editor

Transacted Query Action Editor

Transacted Stored Procedure Action Editor

Backup SQL Server Database Action Editor

Begin SQL Server Transaction Action Editor

Close SQL Server Connection Action Editor

Commit SQL Server Transaction Action Editor

Open SQL Server Connection Action Editor

Run SQL Server Query Action Editor

Set Shared Property Action Editor

Check Service Exists Action Editor

Check File Exists Action Editor

Check Folder Exists Action Editor

Read File Version Action Editor

Set Display Version Action Editor

AppLife Manager Set Update Version Action Editor

AppLife Manager Find Install Directory Action Editor

Missing Action Place Holder

License Form

Options Form


Support

More:

Kinetic Jump Support


The AppLife® Update Solution

More:

What is AppLife Update?

Update Features

Requirements

License Agreement


Update Actions

More:

Update Actions

Expansion Variables (Shared Properties)

Action Conditionals

AppLife Update Actions

Making Custom Actions


Using AppLife® Update

More:

Updating Your Software

Building Your Update

Managing Published Updates

The AppLife Update Windows Service

Deploying an AppLife Update Enabled Application

Update Options

AppLife Update Components