Configure for AppLife Manager
AppLife Manager is a Windows Service and Interactive System Tray interface that supports deploying and maintaining Windows Server and Client applications with no integration required into the application source code.
Software publishers can deploy update packages through AppLife Manager, completely automated or manually initiated by an end-user through the AppLife Manager UI. Once installed, AppLife Manager can be configured for one or more AppLife Cloud Subscriptions.
Applications maintained by AppLife Manager are configured through the AppLife Server dashboard.
There are many options for deploying and maintaining applications with AppLife Manager.
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.
%ApplicationId% - Expands the string value of the current application id guid.
Windows Environment Variables
%ProgramFiles%
%ProgramFiles(x86)%
%CommonProgramFiles%
%CommonProgramFiles(x86)%
%LOCALAPPDATA%
%APPDATA%
%ALLUSERSPROFILE%
%PUBLIC%
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.
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.
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;.
Sets the number of minutes between update checks. Value must be greater than 5. The default is 1440 (24 hours).
Sets the method of determining the Currently Installed Version.
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.
AppLife Manager will automatically upload failed update execution logs to AppLife Cloud for troubleshooting client update issues. Failed logs can be viewed through the Dashboard. This behavior can be disabled by checking the option to Disable Sending Failed Execution Logs.
The global behavior settings can be overridden with local behavior settings when this option is selected. Enabling this settings allows all clients of the application to configure local behavior overrides. Local behavior settings can also be set on specific clients only through the Client Configuration page.
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:
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.
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
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, or the AppLife.Api.dll in .Net 5. These assemblies are distributed through NuGet.
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 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
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.
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.
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.
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.
Updates occasionally fail on deployed clients. When a failure occurs, the best tool available to identify why the failure occurred is the update execution log for the failed update. Execution logs are created on the system that runs the update and can be retrieved from the system. Unless configured not to, AppLife Manager automatically uploads a failed update log to AppLife Cloud.
To view the failed update log, navigate to the Client page.
The log can also be seen locally through the AppLife Manager Update History dialog.
The ability to set Local behavior settings on any of your deployed clients allows for overriding the global settings set for the application. Local behavior settings can be set globally from the AppLife Manager settings page on the AppLife dashboard. They can also be enabled for specific clients through the Client dashboard page.
Once enabled, in AppLife Manager, there is a Local Settings Command visible.
The behavior-based settings can be overridden locally. In the example, updates are configured to be applied automatically between the hours of 2:00 AM and 6:00 AM, and the frequency of update checking has been increased to 30 minutes.
When an application has local settings applied, an adorner is applied.
Note: Updating can be disabled for an application through local settings.
AppLife Manager uses the AppLife Server Passcode Style access management system, where each installed instance of AppLife Manager is assigned a Client Access Key. The Client Access Key is assigned during the subscription configuration.
When an AppLife Manager client initiates cloud communications, the configured Client Access Key is submitted and compared with the Client Access Lists enabled for the subscription 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.
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 ‘*’).
Applications can be configured through the AppLife Server Dashboard. To manage application settings, click the Application row on your dashboard.
Once on the Application View, click on the Actions menu.
The Enable AppLife Manager Integration configuration option is on Manager Settings page.
