Introducing AppLife Cloud Version 6!

We’re excited to announce the release of the next version of AppLife Cloud. It’s never been easier to publish and maintain deployed Windows software with AppLife! Along with a new look and feel, version 6 strengthens the integration of the cloud dashboard, builder tools and AppLife Manager software. On the backend, we’ve increased performance, reliability and extensibility of the platform, which will lead to a better experience and more frequent feature additions going forward.

Here’s a summary of what’s new…

Dashboard

  • New Identity/Authorization System
    • Two Factor Authorization
      • Email
      • Authenticator App
      • Hardware Key
    • More strict password requirements
    • Email usernames
  • Responsive Layout
  • View Failed Client Execution Logs in Dashboard
  • Persisted Sorting, Paging, Filtering Navigation
  • Performance and Scalability improvements
  • IP Based Publishing Filter

AppLife Builder

Formerly called Make Update, AppLife Builder has been completely integrated with AppLife Cloud. You’ll notice the changes upon launching AppLife Builder, as your prompted to log on. All of your build configuration information is now centrally managed within AppLife Cloud. AppLife Builder makes it easier to build and publish update packages for your cloud applications.

  • Integrates directly with AppLife Dashboard
  • Simplified, per-user installation without licensing
  • Key Pair Encryption using local password
  • Edit published update Access Control configuration
  • New Install .Net 5 Action
  • New Install .Net 4.8 Action

AppLife Manager

We’ve added many features to AppLife Manager that makes it a compelling option over direct AppLife integration. Completely manage the distribution and maintenance of your applications without any source code integration. Your maintenance process can be as automated or manual as you prefer, based on simple dashboard configuration. In version 6, deploying applications with AppLife Manager has never been easier.

  • Organization Information in UI
  • More visual feedback during update process
  • Application Update History dialog
  • Publisher and Application Information dialog
  • Failed Update Execution Log Reporting to Cloud
  • Local Behavior Settings Options
    • Globally for all deployed clients
    • Enable for specific clients
  • Optionally require admin authorization for new applications
  • Custom Publisher Code option


API Changes

There is a new .NET 5 (Core) integration assembly. The .Net 4.x integration assemblies are now built on .NET 4.5 and include new TAP based asynchronous integration. The biggest change is that the AppLife integration API is now deployed through NuGet and integrated directly into your Visual Studio projects. You can find them here…

AppLife.Api

AppLife.Api is for .NET 5 applications and includes the primary AppLife Update controller and visual controls for the .NET 5 Windows Client extension (WinForms and WPF)

Kjs.AppLife.Update.Controller

This NuGet package is for applications targeting .NET 4.5 thru 4.8. It includes the primary AppLife Update controller and visual controls for WinForms.

Kjs.AppLife.Update.Wpf

This NuGet package extends and depends on the Kjs.AppLife.Update.Controller package and includes visual controls for .Net 4.5 thru 4.8 WPF applications.

In the Future…

We plan for frequent feature additions on the new platform. The next release is already in development and will add user management for subscription owners, allowing for adding and removing subscription users and modifying the application privilege’s of subscription users. We’re localizing AppLife Manager to German, Spanish, French, Italian, and Dutch with more languages to follow. Were adding more Update Actions too.

More to come…

Insert Raw Xml During an Update

The Change Xml Node action can be used to add content to an Xml Node, and it can also insert additional, or raw Xml into a file.  To insert raw Xml, uncheck the option to Use Xml encoding in replacement text.

Here’s an example of when this feature comes in handy.  The objective is to insert two new entries into the web.config assemblyBinding node.  We can replace the entire content of the target node as raw Xml.  After an update, we end up with:

Here’s what is inserted if we do not uncheck the box:

Clearly not the desired result.

GO Statements in Run SQL Action

What’s in a GO statement?  Quite a bit actually.  Contrary to popular belief, GO is not actually part of T-SQL.  It is a command recognized by the sqlcmd and osql utilities and the SQL Server Management Studio Code editor.  When we created the Run SQL Query update action, we included parsing on GO during the update build process, which allowed users to execute their migration scripts when including them as a .sql file.  This works nicely for pure SQL.  However, when SQL is inserted into the action editor, it is parsed real-time as the update is executing. In this context, the the SQL was passed directly into a SQLCommand object and executed.  GOs don’t fly there.  So why wouldn’t one just put their SQL into a .sql file and let the build process parse the GO statements?  Shared Property expansions.  If you want to use Shared Property information as part of your SQL input, things became difficult.  With AppLife Update 5.1, we’ve added GO parsing to the update engine and what was once difficult, is now quite easy.

Introducing AppLIfe Update 5.1

AppLife Update 5.1 was released today. Some new features added includes:

  • Improved Run SQL Query Action

  • The new Run SQL Query action now supports the use of the GO statement in SQL added directly to the action editor.  GO has always been supported in linked query files, but not in directly entered SQL text.  This is significant as the only place Shared Properties are supported is within SQL entered directly in the action editor.

  • Pre/Post Build Script Update Version Variable Definition

  • Pre/Post build scripting now has access to the Update Version being built within the scripts.  This is especially useful when local paths include the version being built and scripting around those file paths must take place before or after creating a new update.

  • New Shared Property Action Options

  • There are two new options when creating a Shared Property through the Set Shared Property action.  Number (double) values can now be created. Also, the Update Publish Date/Time is available to be assigned to a Shared Property.

  • New Display Property option on the Execute MSI Action

  • The text displayed to the user during the execution of an MSI using the Execute MSI action is now configurable.

  • Added API Access to Update Summary Text

  • Update Summary text from any locale’ can be accessed through the Update Controller API.

Replicate Updates Locally

In situations where there are many deployed systems located on the same local network combined with a need to minimize bandwidth utilized in retrieving application updates it is advantageous to provide a means to download update packages only once for everyone. With a new feature of AppLife Update 5.0, creating this ability is quite easy.

After an Update Controller checks for and downloads available updates, you can now save the downloaded package(s) and Director.Xml file to a local folder by calling the Update Controllers SaveUpdatesToLocal method.

As an example, let’s modify the C# Simple Quick Start project that ships with AppLife Update to first check a local folder for updates before checking the public location. Any updates downloaded from the public location will be copied locally for other local systems to find. To accomplish this, we’ll add a few Main form variables to hold the Public and Local update locations.

1:  public partial class Form1 : Form {  
2:   private string mPublicUpdatePath = @"http://www.kin…/SaveToLocalExample";  
3:   private string mLocalUpdatePath = @"P:\Updates\SaveToLocalExample";

This Quick Start uses the UpdateDisplay control to manage the update process.  To integrate with that process, we will use the CheckForUpdateCompleted and the DownloadUpdateCompleted events of the Update Controller.

Basically we are going to initially check the local update folder for updates.  If no updates are found locally, we’ll check the public update folder.  If we find any updates in the public location, we’ll save them locally with the new SaveUpdatesToLocal method.  So here goes.

Modify the Update Controller’s default Update Location to be the local update path, and then attach to the two events.

First, lets handle the CheckForUpdateCompleted event.  This event fires whenever the Update Controller completes an update check.  If the private location was checked, we’ll just switch to the public location and check again.

1:  private void updateController1_CheckForUpdateCompleted  
2:       (object sender, CheckForUpdateCompletedEventArgs e) {  
3:       UpdateController c = sender as UpdateController;  
4:       if(c.UpdateLocation == mLocalUpdatePath) {  
5:            //we checked the local path. If we didnt find any  
6:            //updates, lets check the public path  
7:            c.UpdateLocation = mPublicUpdatePath;  
8:            c.CheckForUpdateAsync();  
9:       }  
10:  }

And then finally, in the DownloadUpdateCompleted event, we’ll look to see if the update that was just downloaded came from the public location.  If so, we’ll save it to the local folder using the new method.

1:  private void updateController1_DownloadUpdateCompleted  
2:       (object sender, AsyncCompletedEventArgs e) {  
3:       UpdateController c = sender as UpdateController;  
4:       if(c.UpdateLocation == mPublicUpdatePath) {  
5:            //downloaded an update from the public path. Save it locally  
6:            c.SaveUpdatesToLocal(mLocalUpdatePath, false);  
7:       }  
8:  }

If multiple update packages were downloaded as a chain collection, all of the update packages will be saved by the SaveUpdatesToLocal method.

Applying Cached Updates

A new feature of AppLife Update 5.0 allows your applications to easily apply updates that have previously been downloaded by your applications. This is very useful when your application resides on field computers that come and go from your primary network.

All that is required to do to use this feature is to set the Update Controller’s Disconnected NetworkEnableOfflineUpdates property to true. By default, this feature is not enabled. Once set, any updates that get downloaded are made available to the update controller until they are applied. They will be available even if network connectivity is lost.

A common use-case for this feature is when applications are configured to check for and download any updates upon application startup and at certain intervals while operating, but defer the update process until the application is shutdown or restarted. In these situations, the deferred updating process might well take place when the deployed system has been moved away from the network. If the EnableOfflineUpdates property has been set, the update process can proceed whenever it is convenient for the user, regardless of whether or not a network connection is available.

Introducing AppLife Update 5.0

AppLife Update 5.0 was published today and includes many new features.

AppLife Update Server Support

AppLife Server is the most secure and reliable platform to host AppLife Update packages.  With the release of AppLife Update 5.0, App

Enable Cached Update Checking

Previously downloaded but not yet installed updates are now cached locally and can be used to apply an update at a later time even if network connectivity is no longer available.

New Update Actions

Check File Exists

Update Display Version

Install .Net Framework 4.5

Read File/Assembly Version

Custom Update Window Improvements

Support for including IUpdateUI implementation dependency assemblies into the update package.

Save Downloaded Update and Director.Xml Locally

API extensions allow for saving downloaded update packages and corresponding Director.Xml to a local folder.  This extension can be used to implement an updating scheme where multiple local installations can download an update package once and use it multiple times.

Expand Update Possibilities with Manual Versioning

AppLife Update identifies the existence of an update through the use of versioning. The update controller deployed out there on client systems knows the current version that is installed and, after performing an update check, knows the update packages that have been published for the current version. With this information, the process can continue. Most commonly, a deployed client’s current version is determined by the .Net Assembly Version stamp of the host .Net executable. Using an assembly version, the current version is readily available, and when the host executable is replaced, presumably the replacement executable has a new higher assembly version. The AppLife Update solution makes it very easy to use the .Net Assembly Version stamp in a very hands-off way, making it the most common scenario. It is not the only method available though, and looking at versioning a little differently opens up many possibilities.

What’s Possible with Custom Versioning

The thing about using an Assembly Version stamp is that the executable must be rebuilt in order to create an update. There are circumstances where it is favorable to be able to update an application installation without rebuilding the primary executable. Sometimes what you might want to update isn’t even an application at all. AppLife Update can be used to package and automatically deploy updates to all kinds of application sub-systems, such as reporting templates, map files, and other types of document repositories. The ease with which you can package any information, as well as a code process to execute, into an update package and the flexibility available to implement a simple check, retrieve, and apply process using an AppLife Update Controller makes it possible to be very creative with updating application components independently. Versioning is key to any update process using AppLife Update, so here is a simple and effective method for versioning just about any type of update process.

Xml File Versioning

The basic idea behind Xml File Versioning is to place a simple Xml file on the client PC that holds a version stamp. We’ll read that version stamp from the file and set the Update Controller version based on the content so that we can publish updates that target a specific version. Within the update, we’ll use an Xml Update Action to modify that version file contents so that after the update is executed, the version file will then represent a newer version based on the modifications that the update made.

Note: We will use a stand-alone Xml file, however applications that utilize a .config already have an Xml file readily available for versioning sub-components. Adding a new appSettings value to an existing .config file can accomplish the same result.

We’ll need a snippet of Xml to hold a version stamp. A file like this will do just fine:

Filename: Version.Xml

<?xml version=”1.0″ encoding=”utf-8″?>
<version>
<currentVersion value=”1.0.0.0″ />
</version>

Read the Current Version and Setup the Controller

To setup an Update Controller for manual versioning, ensure the UseHostAssemblyVersion property is set to false. With that set, your code can set the Version property based on the content of the Version.Xml file.

1:  private Version getCurrentVersion() {  
2:   Version currentVersion = null;  
3:    using(XmlReader reader = XmlReader.Create("Version.Xml")) {  
4:     reader.ReadToFollowing("currentVersion");  
5:     string versionStr = reader.GetAttribute("value");  
6:     if(!string.IsNullOrEmpty(versionStr)) {  
7:      currentVersion = new Version(versionStr);  
8:     }  
9:    }  
10:   return currentVersion;  
11:  }

With the version set, you can call CheckForUpdate or CheckForUpdateAsync on the Update Controller and find updates for the current client version.

Applying Updates without Shutting Down the Host Application

When updating sub-systems, it is often not necessary as well as undesirable to shut down the host application. If the update will operate on files that are not locked, or can be unlocked without shutting down the application, your sub-system updating process can operate seamlessly by using a few of the options that are available when applying an update. To accomplish this, pass in a parameter to the ApplyUpdate method. The following options will apply an update without shutting down, without showing an update window (silently), and the method call will wait for the update to complete (synchronously). Any combination of these options can be used.

1:  mUpdateController.ApplyUpdate  
2:  (ApplyUpdateOptions.NoShutdown | ApplyUpdateOptions.NoUpdateWindow |  
3:   ApplyUpdateOptions.WaitForCompletion);
Updating the Version.Xml file during an Update

Maintaining the Version.Xml file is very easy and once we set it up, we can forget about it. Each update will modify the version file based on the update version that is being executed. We can accomplish this by adding two update actions to the update action list.

  1. Use a Set Shared Property update action to access the current update version value and assign it to a Shared Property.
  2. Use a Change Xml Node update action to modify the Version.Xml file on the client to match the current update version.

Action 1

Action 2

That’s it. Precede these two actions with the update actions that perform the necessary work on the client and proceed to publish updates that your application can find and seamlessly apply. An Update Controller and manual versioning opens the door for many creative updating scenarios utilizing the power and flexibility of the AppLife Update engine.

Application Update Customization using Custom Data

When publishing updates for applications, it is often helpful to implement rules that can be applied on an update-by-update basis. With AppLife Update, the custom data field provides this opportunity.

clip_image001

With each update, you can specify a custom data string to go with the update. This value is then available to your application after an update check has been performed. Your application can interrogate the value and control additional logic based on the information. As an example, when creating updates for AppLife Update, we use this field to know whether or not the update requires Visual Studio to be closed. If it does, we add a RequiresVSClosed property to the custom data field.

 

Accessing the Custom Data in Your Application

After an update check, the update controller has a CurrentUpdate property that holds an UpdateInformation object. This object has a CustomData property that holds, you guessed it, the Custom Data string that you specify when publishing the update.

Code Snippet

if(updateController1.CheckForUpdate()) {

string customData =updateController1.CurrentUpdate.CustomData;

}

 

Changing Custom Data after Publication

Custom Data can be modified after an update has been published without having to re-build the update package itself. To modify custom data, you can Manage Published Updates…

From the Manage Published Updates dialog the Custom Data string can be modified and then published.

clip_image002

A Class to Parse Name/Value Pairs

A common approach to be able to provide multiple pieces of information through the custom data string is to use a name/value pair syntax, and then extract this information within your application code. To help with this, here is a class that will parse a custom data field using a name=value; syntax.

AppUpdateCustomData.cs and AppUpdateCustomData.vb

Using this class, you can easily extract and use multi-value custom data strings in your applications.

clip_image003

Using the AppUpdateCustomData class:

Code Snippet

1:  if(updateController1.CheckForUpdate()) {  
2:    Kjs.AppLife.Update.AppUpdateCustomData customData = newKjs.AppLife.Update.AppUpdateCustomData(updateController1.CurrentUpdate.CustomData);  
3:   string myValue1;  
4:   string myValue2;  
5:   if(customData.DataTable.ContainsKey("MyName1")) {  
6:  myValue1 = customData.DataTable["MyName1"];  
7:   }  
8:   if(customData.DataTable.ContainsKey("MyName2")) {  
9:   myValue2 = customData.DataTable["MyName2"];  
10:   }  
11:  }

In conclusion, the Custom Data field provides the means for update publishers to assign information to individual update packages that applications can use to control application update behavior.

Using a Pre-Build Script for File Automation

When an application update is built with AppLife Update, you can define a pre-build and post-build batch script to run during the build process. This ability to easily interact with the build process provides, among other things, the means to move files around on the build system before the actions in the action list are built. This allows for accomplishing automation tasks that might otherwise require a custom action builder. Action builders are more powerful, but more technically complicated as well. Creating a pre-build script is easy. In this post, I will demonstrate the use of a pre-build script to remove the necessity of manually modifying an action configuration before building an update.

Hub and Spoke Update Deployment Example

The Hub and Spoke Update Deployment solution lab outlines how AppLife Update can be used to “update” multiple application update servers. This is a part of a process that allows a software publisher using AppLife Update to maintain many remote update servers for their applications. With remote update servers, client systems can check for and retrieve updates from servers that are on their local networks, instead of from a global update server over a wide area network.

The update actions that maintain those remote application update servers simply add two files to the update. The first file is the Director.Xml document, and the second file is the newest update package built for the application. This file is named major.minor.build.revision.zip based on the current version number of the application. The issue here is that the version number always changes, and when a standard Add & Replace Files action is utilized, the action configuration must also change with each new update in order to address the proper update package.

With a little help from the pre-build batch script and using a different update file action, we can remove this requirement to manually modify the update configuration with each update, which makes creating the remote server update a one-step process using the AppLife Make Update tool. Configured this way, the remote server update build can also be easily incorporated into a larger automation process using the Command Line build utility.

The Pre-Build Script

The project pre-build script can be accessed from the project settings dialog, under the build tab. When creating a pre/post build script, there are replacement values that can be inserted into the script. Replacement values provide access to contextual information from the update project. We’ll be taking advantage of the $UpdateVersion$ and $ProjectDirectory$ replacements to accomplish the goal.

The goal of the pre-build script is to empty a working folder, and then add the two files that will be included in the update to the working folder. The two files will be the Director.Xml file and the application update package that matches the designated update version. The script will copy these files from a local folder that represents the primary application update folder, and will be addressed in the script using a relative file path from the current AppLife Update project file location. After the pre-build script runs, there will be a working directory that contains two files. The Director.Xml file and the application update package (a.b.c.d.zip) file that matches the defined update version number. Then, we just need to use an update action to add these files to the update. Here is the script.

Set WorkingPath=$ProjectDirectory$\Current Update

Set AppUpdatePath=$ProjectDirectory$\..\Application Updates

Del %WorkingPath%\*.*

Copy “%AppUpdatePath%\Director.Xml” “%WorkingPath%”

Copy “%AppUpdatePath%\$UpdateVersion$.Zip” “%WorkingPath%”

Using replacements, we have access to the version number of the update currently being built, and we also have access to the path of the .aup AppLife Update project file. We use this information to copy the correct update package from the correct folder.

The Update Actions

With the pre-build script, the files that we want to add to the update is going to be sitting in a folder named Current Update that is a sibling to the AppLife Update .aup project file. Normally, we wouldn’t care which order the files are copied during the update, and the most obvious update action to use would be the Add Folder Content action. This action would simply add both of the files to the update as the update is built, and then write them to the designated client directory as the update engine executes the action on deployed clients. In this case though, we do care about order. We want the update package file copied first, and then the Director.Xml file. Because of this, we’ll use the Masked Add & Replace files action. With this action, we can apply a mask to the files that will be added to the update package. The first action will add the update package, and the second action the Director file. By applying a mask of (*.zip), the update package is added to the update.

To add the Director.Xml file to the update, we could have chosen the Add & Replace Files action, but for consistency we use another Masked Add & Replace action with a mask of *.Xml.

With these two actions in place, the appropriate update package file and the corresponding Director.Xml file is added to the update package and will be placed in the application updates folder on remote update servers. To publish an update, no changes are necessary to the update project. We simply open AppLife Update and walk through the publish wizard. When the update version is defined in the wizard, the correct application update package is automatically included.

Scroll to Top