AppLife Update

Deploying Applications with AppLife Cloud

AppLife provides the ability to easily deploy and maintain many applications on your Windows clients and servers. By installing AppLife Manager on your deployed systems a channel is created with which one or more applications can be deployed and maintained using AppLife packages. This is the first of a series of posts that will discuss and demonstrate the use of AppLife tools to deploy software. This series will include:

  1. Deploying an application with AppLife
    Using mostly default settings, we’ll start from a brand new AppLife subscription and deploy a .NET WPF application through AppLife Manager.
  2. Explore Manager Deployment Options
    After looking at a default deployment in the first post, we’ll demonstrate the different configuration options available with AppLife Manager.
  3. Explore the AppLife Engine
    The deployment package in the first post added two files to the installation directory. In this post, we’ll look at other actions and demonstrate the features of the AppLife Update engine.
  4. Using the Dashboard
    The AppLife Dashboard provides the ability to control which of your deployed systems get applications and updates. It can help in troubleshoot defective packages, can identify which clients are running what version of your applications and more. The final post in the series will look at how the dashboard enhances your AppLife deployment model.

Connecting AppLife Manager to your Subscription

The AppLife Manager application gets installed on all of the systems that will run your software and connects your deployed clients to your AppLife subscription. AppLife Manager is downloaded from AppLife Update home page (www.applifeupdate.com). Once installed, you’ll connect Manager to your subscription through a registration process. To register AppLife Manager, you’ll need your Publisher Code. You’ll also need to define a Client Access Key. The Client Access Key will be a value that identifies an individual client, or perhaps a group of clients.

Your publisher code can be found on the Subscription view of your dashboard and can be replaced with a custom value.

Find your publisher code

Defining a Custom Publisher Code

You can set a custom publisher code for your subscription. One that is more meaningful and easier to remember, such as your domain name. A custom publisher code is set from the Subscription view on your dashboard.

With your publisher code entered, the default settings of your initial application will allow it to be discovered. It’ll be displayed within AppLife Manager. Nothing is actually installed on this deployed client yet, as there are no AppLife packages published for the application.

Deploying an Application

We have an application, called First Look that we want to deploy. We are going to effectively XCopy deploy our First Look application to our client machines through AppLife Manager. To accomplish this, we’ll create and publish an AppLife package that, when executed, will place our application on the deployed client. Once published, AppLife Manager will automatically discover and apply the package.

To create the package, we’ll use the AppLife Builder application. Like AppLife Manager, this can be downloaded from the AppLife Update home page. Once downloaded and installed, log into AppLife using your credentials. Select your subscription application. You’ll be prompted for the basic information about your application.

  1. Application Name
    Set this to your application’s name. In this case, First Look. Note that this will change the name displayed in AppLife Manager.
  2. Executable Name
    Set this to the name of the primary executable of your application. FirstLook.exe.
  3. Local Working Directory
    This is a local value that defines the local directory for your application and will be used for relative paths later. For custom software, this is usually a bin directory or an output directory of your build process.

AppLife Actions

An AppLife Package consists of a series of Actions that will take place when the package is executed on a deployed client. There are many actions available. This first package is going to include only one action. An Add & Replace Files action, which will copy two files to the designated Application Directory. When AppLife Manager discovers and applies this package, these two files will be copied.

By default, AppLife Manager applications will check for new versions every 24 hours. After having published this package, any connected clients will install First Look on their next check. AppLife Manager can also be refreshed manually, which will find the application immediately.

Deployments in the Dashboard

When a client applies an AppLife Package, the results are reported to your dashboard and can be reviewed there.

Summary

Using a new AppLife Subscription, we just built an AppLife Package that deploys our existing application through AppLife Manager. With the exception of setting a custom Publisher Code and changing the application name, we used entirely default settings. In the next post, we’ll explore the configuration options available through AppLife Manager that will let you customize the deployment and maintenance model to better fit different scenarios.

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…

Reviewing Update History with AppLife Server

There are many advantages to hosting your update packages with AppLife Server over a standard http file server. One big advantage is the ability to drill into your deployed install base and investigate what is going on out there with your applications. Once logged in and navigated to your specific application, using the search box to filter down the client list provides a lot of information. Say you want to see which deployed clients have not updated to the most recent release. Just enter the previous version number in the search box and you’ll be looking at all of the clients that are still running your previous version.

clip_image002

You can search for any of the values listed for your deployed clients. To review the update history of a specific computer, search for a computer name or known Client Access Key.

Here’s my laptop (BRIANHLT2).

clip_image004

The last time I ran this particular application was on 2/1/2016. And to see all of the update history for this installation, click on the information icon.

clip_image006

And if we look into the last update from version 1.3.0.1 to 1.3.0.2 we have:

clip_image008

If this had been a failed update, information about the reason for the failure, and most importantly, the location of the update execution log on the deployed client would be displayed.

clip_image010

Access to deployed installation status can be very valuable in troubleshooting issues that arise as well as ensuring updates are being deployed as you expect them to be. Hosting with AppLife Server provides all of this information to you.

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.

image

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:

Non - Encoded Insert

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

Encoded Insert

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.

image

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.

image

image

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

clip_image001

Action 2

clip_image002

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.