AppLife Cloud

Use the WiX Toolset and AppLife Cloud to Install and Maintain Software Applications

Packaging software for Installation on the Windows platform is most commonly accomplished by using the Windows Installer. The WiX installer is one of the many tools available to create Windows Installer packages (.msi files). WiX Installer Xml is a popular and well documented toolset with a large library of online resources to help new integrators get started.

AppLife Cloud is a turn-key software distribution and updating online service that provides the functionality to publish, control and monitor the distribution of software, and future updates, over the internet. AppLife can be implemented using an installable client application that, when connected to an AppLife Subscription, can install and maintain one or more applications on a Windows computer, requiring no source code integration with any of the maintained applications. Alternatively, AppLife can be integrated into an application’s source code to deliver a tightly coupled maintenance process for installed software.

WiX, Major Upgrades, and AppLife

In this article, we’ll use the WiX Toolset to create a Windows Installer for our application that implements a Major Upgrade scheme. Then, we’ll use AppLife Cloud tools to create an online distribution channel for the application. To help support the use of AppLife, we’ll also implement an ARPINSTALLFOLDER Custom Action within the WiX project, which writes to the Windows registry the local directory that the application gets installed into, which AppLife tools use.

The AppLife Builder tool is used to package the application Msi file created by WiX and publish it to the AppLife cloud, where it can be discovered and executed using AppLife Manager. AppLife Manager is a small client software that lives in the Windows System Tray, capable of automatically deploying and maintaining many applications through the AppLife Cloud. As an alternative to using AppLife Manager, the AppLife API can be used to integrate update discover and execution functionality directly into the Windows application.

These examples are based on the standard templates used by Visual Studio 2022 and the Wix Toolset to create the .Net example application and the WiX created Windows Installer(.msi).

The Example Application

Our example application will be a .Net 7 Windows Forms application, created using the Visual Studio application template. We’ll add no functionality as we will be focusing on packaging the application for deployment and future continuous updates and maintenance.

Create the WiX Installer

WiX uses XML files to define how the Windows Installer is created. Compared to other GUI based Windows Installer build tools, WiX has a larger learning curve. After paying the early learning price to get started, our experience suggests literally every objective thereafter relating to Windows Installer functionality is easier accomplished with WiX than other tools.

To get started, install the WiX 3.11 toolset, and then in Visual Studio WiX, the WiX v3 Visual Studio 2022 Extension. To be clear, Visual Studio is not necessary to use WiX, but since we are using Visual Studio and .Net, we’ll use the extension as Visual Studio makes for an excellent XML editor and we can use Visual Studio environment variables to help with accessing sourcing the files and assemblies for inclusion.

Create a new Setup Project using Visual Studio

We’ll make a few immediate changes to the standard template.

1. Embed the CAB file. We want a single MSI file to deploy. To support this, we make a change to the Media Template element.

2. Add ARPINSTALLLOCATION custom action to the installer. This action writes the installation directory to the registry and allows AppLife to lookup the install location using the registry information.

3. Support Major Upgrades. The WiX template is already configured to support Major Upgrades. If starting from an existing WiX project, verify that the UpgradeCode attribute is set on the Project element, the Id attribute is set to *, and the MajorUpgrade element is present in the Product Element.

4. Add a reference to the .Net Application to the WiX msi project. This allows us to use environment variables to source the files we’ll add to the installer.

Add Files to the Installer

This is the output directory of the Visual Studio application. The Windows Installer must deploy the highlighted files. We’ll add the necessary WiX components.

And in the Wix Project….

Now we can build the Windows Installer project and generate an MSI that we will distribute and deploy with AppLife.

Deploy with AppLife Cloud

Create an AppLife Application. If you don’t already have an AppLife Subscription, here’s how to get started.

We’ll start with a newly created AppLife application. Since we’ll be using the Windows Installer, our action list will include only one action, which will execute the Windows Installer file we created with WiX.

Add a Run Windows Installer action to the action list. Select the Windows Installer to run, select the Quiet/Silent option, and finally the Set AppLife Manager Application Directory option.

Publish an AppLife Package

Create version 1.0.0.0 by clicking the Create an Update… button.

For Access Control, leave set to the default Application option. Access control lists can be configured to publish an update package for a specific group of users, but for this example we are using anonymous access and publishing for everyone.

Enable AppLife Manager

To enable any client connected to your AppLife Subscription with AppLife Manager to discover and install this example Windows Forms application, we need to configure the application through the AppLife Cloud dashboard.

And we’ll also set the application access control to allow anonymous access.

With these actions taken, AppLife Manager can discover and deploy this new application. Future updates are then automatically discovered and installed.

Conclusion

AppLife Cloud and the WiX installer combines to create an excellent software package and distribution model for new and old applications that target the Windows platform. With WiX, you can create an MSI that can be installed on any PC, and when combined with AppLife Cloud, you have an instant global Software Distribution network that can be used to deploy and maintain all your applications across your user-base. This short example just scratches the surface on what can be accomplished with both tools. WiX enables everything that is possible with the Windows Installer technology and includes many tools and techniques that we did not touch on to manage large-scale installations. AppLife extends this with a solid distribution system, many actions that can be taken during a package execution far beyond executing an MSI, and access control that can all be accomplished without any source code integration to your applications. Please visit the following additional online resources on these technologies for more information.

The WiX Toolset

AppLife Cloud

AppLife Documentation

Controlling Access to AppLife Applications and Packages

AppLife Cloud provides an excellent channel to distribute custom software applications to Windows desktops and servers. For many subscribers, they publish their packages using the default anonymous access settings and it works great for them. But there are many scenarios where it becomes important to filter access to specific applications and packages. The most common scenario is for limiting new versions to testing and QA installations and then opening them up later for wider distribution. Whatever the scenario, when applications require limited access, AppLife Cloud provides a simple method that works well. Our method works like this…

A string token is assigned to each installation, called a Client Access Key (CAK). Client Access Keys do not have to be unique. Through your dashboard you can create lists of Client Access Keys. These lists are assigned to Applications and AppLife Packages which determine their visibility to installations checking for packages. It’s that simple. In this post, we’ll review how to work with Client Access Keys and Access Lists in AppLife Cloud.

Assigning Client Access Keys

Client Access Keys can be any string value and are specific to the applications domain. While individual installations don’t require unique Client Access Keys, we recommend creating unique keys for each application installation. This not only provides the most flexibility in controlling access to Applications and Packages, but it allows for better monitoring your install base throughout the life of your application within your AppLife online dashboard.

AppLife Manager

When using AppLife Manager on deployed clients, the Client Access Key is set when AppLife Manager is connected (registered) to your AppLife subscription. When installed independently on a computer, the Register Subscription command is used.

When AppLife Manager is installed through automation, a subscription is added through a Command Line Action.

AppLifeManagerInstallDir\AppLife Manager UI\RegisterNewServer.exe <SubscriptionId> <ClientAccessKey> [<disableAppApprovals>]

Setting Client Access Key through Command Line

AppLife Controller API

When the AppLife API is used through NuGet to integrate an update process directly into your application, the Client Access Key is set as a property value of the Update Controller object.

Using an Update Controller to set Client Access Key

Creating Access Lists

Access Lists are collections of Client Access Keys that can be assigned to Applications and AppLife packages to control visibility of these assets.

Individual Access Lists are “owned” by an application and the editor is opened through the dashboard Application view. When viewing any application in your dashboard, the Client Access view can be opened through the Application Menu.

From there you can control most of the features of Access Control. Clicking to Manage Access Lists displays all of the applications Access Lists. By selecting a list, you can edit that list, clone the list into a new one, delete it or copy the entries onto the clipboard. You can also add a new list from here.

When adding/editing a list, the list name is editable and a list of the Client Access Keys included in the list is displayed. When adding a Client Access Key, the list of existing keys that don’t match the current entry are hidden from view. This helps find an existing Client Access Key in a list and also prevents entering duplicates.

Bulk Add

To assist in adding an existing list of Client Access Keys, there is a Bulk Add option. Using Bulk Add, multiple Client Access Keys can be added at the same time, one per line. This supports using the clipboard to paste from spreadsheets or query results.

Client Access API

In situations where Client Access Keys are managed from a separate supervisory system, Access Lists can be manipulated through the Client Access API. This will allow lists to be created, removed and entries added and removed. To use the Client Access API, it must be enabled per application and a token must be generated. The different API actions are called through HTTP Post to the respective addresses. More information is available in the AppLife Cloud documentation.

Sharing Lists

Access Lists are created and maintained for individual applications, however lists can be shared across all applications within an AppLife Subscription. This allows a single set of lists to be maintained for subscribers with multiple applications that use some or all the same Access Lists. To share an Access List, the list must be selected as shared.

On applications where this shared list is to be used, toggle the option to Use Shared Lists. Any lists shared through any subscription application will be available for selection.

Assigning Access Lists

With Access Lists created and shared as necessary, they can be assigned to Applications and Individual AppLife packages to control exposure to clients. By default, new applications are configured for Anonymous access. To filter access based on Client Access Keys, disable the Allow Anonymous Access setting, and then check the appropriate access lists that should be able to see the application.

Assign Lists to Individual Packages

Access to individual AppLife packages can be set during publishing and can be modified afterwards through the dashboard or through the AppLife Builder application. A common use-case is to publish packages initially for testers, and then open it up for wider distribution through the dashboard later. When publishing, the Version Access Mode options are Application, Version, and None. When Version is selected, the Access List selections will override the application level selections.

Version Mode Access Entries can also be modified through AppLife Builder.

Modifying Version Access through AppLife Builder

Version Access Lists can also be assigned through the dashboard. Select to edit the individual AppLife package properties by clicking on the row in the Application Versions table.

Conclusion

Visibility of your Applications and AppLife packages published to your AppLife Cloud can be controlled by setting Client Access Keys on each installation and then assigning lists of your Client Access Keys to your Applications and packages.

The AppLife tooling provides the ability to easily integrate Access Control into your dev ops routine. This article provides instruction on how to accomplish access control using AppLife.

Maintaining a Previously Deployed Application with AppLife

We’ve written about deploying and maintaining new applications using AppLife, but what about picking up existing applications that have been deployed over the years? Maybe the application started small, has grown over time but never had a maintenance process built into it. Or maybe it had a maintenance process from the beginning but is no longer working very well. Maybe it’s deployed through XCopy deployment or maybe an MSI installed it. Regardless of circumstance, we’ll show you how to use AppLife to start maintaining that previously deployed application with absolutely no source code integration required.

The Big Picture

In a nutshell, we’re going to use AppLife Manager, which is a Windows Service application that has been or will be installed on your deployed systems, to orchestrate the discovery, delivery, and execution of AppLife packages that will maintain your installed application. For AppLife Manager to perform this maintenance duty, it needs to know where the application is installed and what version is locally present. When AppLife is used in an original deployment, your configuration settings define where and what version gets installed. When picking up an application that has already been deployed through some other method, AppLife just needs to figure out where the application of interest is installed and what version exists there. Once we accomplish this, maintaining the existing application is pretty much the same as any other AppLife maintained application.

We’re going to create an initial AppLife package that will search for the existing application installation and if it finds it, identify what version is present. In the example, we’re using the .Net Assembly version of the primary executable to identify the current version stamp. If the application is not present, we’ll set the version to a value that indicates that the application is not present. That’s all that this first package will do. Then we’ll create another package that installs the current version of the application. At this point, you’ll be able to publish AppLife packages that maintain your deployed application as future versions are created.

Implementing a New Maintenance Process

The first thing we’ll do is create an AppLife Cloud application and configure it as necessary to support the use of AppLife Manager for orchestrating the application maintenance process. You can create a new application through your AppLife Dashboard Subscription view. If you are a new subscriber to AppLife, an application is created for you. To set up the application for maintaining an existing application, we’ll set the Manager Settings like this:

The key setting is the * value for the Application Directory. This instructs AppLife Manager to ignore the server-based setting and rely on an update process to identify the appropriate application directory. We’ll set up that update process in the next step. Here, we’ll also check the box to apply updates automatically and fil in the appropriate process name and primary executable.

Create the Update Package that Searches for Existing Installations

When a new application is created, AppLife Manager sets its version to 0.0.0.0. The plan is to create an initial update package with a version stamp of 0.1 so that when AppLife Manager initiates this application, it will discover only this update package to 0.1. Future updates will target version 0.1 and greater. This 0.1 package will search for the installation that we expect to find and start maintaining. If the application is not found, we’ll assume its not present and we’ll set up a default installation directory that future updates will use to install the application. In any event, after the version 0.1 update package executes, AppLife Manager will know the location and version of the existing application installation and be able to maintain it going forward.

First Action – Set Application Directory

The first action we’ll use is the Set Application Directory action. This action will search the machine for a designated assembly that will identify the current installation directory. The action has some configuration options available and should be configured based on where the existing application is expected to be found. For this example we’ll assume that if we don’t find it in the program files directories it’s not present. We set the assembly’s name that we’re searching for. If the file is not found, we’ll set a default path to be used as this applications installation directory. We’ll use the %ProgramFiles% environment variable. Whatever directory is set will then be placed into a Shared Property that will be used in following actions.

Search for Existing Application Directory

Second Action – Read Version Number

Now that we know where the application is installed, the next step is to determine what application version is installed. This example will use the .Net assembly version, but its possible that determining the existing version might require something else. This action will read the assembly version of the defined assembly, and if the assembly can’t be found, we’ll set a default value of 0.1. The determined version will then be placed in a CurrentVersion Shared Property that will be used in the final action of this update.

Third Action – Set Update Version

The final action will use the CurrentVersion Shared Property to set the AppLife Manager version stamp for the application. Set the action to use an explicit version, and then use the shared property determined in the previous action. When this update gets executed, the version value written here should match the actual version number of the currently installed software.

Create the Update Package that will install the Current Version

For the machines that had the existing software installed, we’re ready to create update packages that will deploy future versions. But for the machines that didn’t have the existing application installed, the next update package should perform a full installation, and target version 0.1 and higher. We’ll create an update package to version 2.0 of My Existing Application. This package will simply package up the entire installation directory and place it in the designated installation directory. Non-trivial applications might require more actions, but just about anything is possible.

Note that the path to the folder to copy files from is relative to the local working directory that is set up when first creating the application builder profile. The working directory can be changed in the project settings dialog.

This action simply packages every file in the local directory and places them in the defined target client folder when the update is executed. This is the application directory discovered or set in the 0.1 update.

In Conclusion

This is the recommended method to start maintaining an application that is already deployed using AppLife. By using AppLife Manger we avoid any source code integration into the application being maintained. The flexibility that using AppLife packages provides in maintaining deployed software opens the opportunity to use AppLife for application that doesn’t currently have a maintenance process built into it. AppLife Manager needs only be deployed once on deployed clients and once deployed, can maintain many applications.

Application Master Passcode

When a deployed application discovers and downloads an AppLife package, the first action taken is a verification of the package using the Public Key value that is already present on the client and the update package signature that comes with the package. Digital signature validation using asynchronous cryptology. If the downloaded update package fails validation, it is never loaded or executed. There are many reasons why a downloaded update package might fail validation, but whatever the reason, a failed validation means that the update package is not identical to the package that was built and published by the author.

Validation ensures that the package that is about to be applied on a deployed client is the exact package that was created and published. The validity of the authentication process performed by AppLife is completely dependent on the sanctity of the project’s private key. This validation process ensures that it is not possible for a third party to create a package that could ever be applied through your software.

So if your AppLife Cloud account was compromised, would your application private keys be at risk? Yes they would, and this could potentially lead to a third party having the ability publish a privileged update package that your deployed clients would apply. Securing your AppLife Cloud account through strong passwords, two-factor authentication, and Publishing IP Address Filtering significantly reduces the probability of a compromised account. Beyond these, another action that can be taken to secure your deployed clients is to implement a Master Passcode on your individual applications.

A master passcode is added to your application locally through AppLife Builder. Navigate to your project settings dialog and open the Security tab. When a master passcode is provided, AppLife Builder uses the code to encrypt the application keypair before transmitting application data to the AppLife Cloud. The master pass code is never transmitted and only stored locally if elected to be.

If a unique passcode is applied to your application, the passcode is never transmitted and an update for the application can never be created without it.

A master passcode provides maximum protection against a compromised AppLife Cloud account, as a final secret that is required but never shared. With this protection comes the reality that a master passcode can never be recovered if forgotten. If a master passcode is forgotten, your deployed clients are forever disconnected from the remote update capabilities provided by AppLife.

For maximum protection from your update process ever being used to compromise your deployed clients, choose and implement a unique strong master passcode.

Publishing IP Address Filtering

Using the AppLife Cloud solution makes it easy to deploy and maintain applications by creating a channel between you the application publisher, and all your deployed client systems. It’s very important to protect that channel and keep it secure. Steps to keep your deployed clients secure started with:

Setting a strong password on your account. We require 8 characters, a letter, a number and special character, but going beyond these minimums is recommended. Using a password tool such as Last Pass makes using long strong passwords very manageable.
Enabling Two-Factor authentication on your account. In addition to a strong password, requiring something you have in addition to something you know adds a significant level of protection.

The next step to consider taking is enabling Publishing IP Address Filtering on your AppLife subscription. This is a great idea if your application publishing always originates from static IP addresses. Once enabled, your application update packages must originate from an IP address in your defined list.

To enable IP Address Filtering, navigate to your Subscription Properties view within your dashboard. IP Filtering is subscription scoped, and covers all applications in your subscription with one list.

Once on the Subscription Properties view, you’ll find the IP Filtering list towards the bottom. When you click the enable checkbox, your current IP Address is automatically added to the list. You can add as many IP Addresses as you need. Save the list and you have successfully enabled IP Filtering.

Enable Two-Factor Authentication

Securing your AppLife Cloud accounts is vitally important. In version 6, we’ve implemented multiple features designed to keep your accounts safe. One of these features is two-factor authentication.

Two-Factor authentication works by requiring a user to follow up your standard username and password credentials (something you know), with an additional authentication step that requires you to provide something you have. This style of authentication removes the potential of compromised credentials (commonly acquired by simply guessing, sophisticated brute force, or duplicate credentials from a less secure site) alone allowing access to your cloud account. With two-factor enabled, the potential imposter would need more than just your credentials. How much more, is configurable. There are three options available.

A one-time passcode emailed to the account email address
A passcode generated by an Authenticator app on a mobile device
A hardware USB key

Email Option

The simplest option available is to enable the Email method. With this method enabled, whenever you sign on to AppLife Cloud on a new device, an email will be sent to the account email address. This email will contain a one-time pass code. Enter this code when prompted and you’ll be successfully authenticated.

Authenticator App Option

An authenticator app shares a private code during setup, and then generates rolling one-time passcodes that expire. Once setup, you will need the device with the app that you configured in your possession in order to log in and authenticate. The app that AppLife Cloud uses is Google Authenticator. Available for both Apple and Android mobile devices, it is a great option and more secure than Email, as it requires physical possession of your device during AppLife Cloud authentication.

USB Hardware Key Option

USB Hardware keys are the third and most secure option for validation. AppLife Cloud supports YubiKey brand keys. Once set up, the physical key must be present to login. The Series 5 key supports USB, USB-C and NFC. You can use your YubiKey for authentication on AppLife Cloud as well as many of the popular sites around the web, such as Google, Microsoft, Amazon, Apple and Twitter to name a few.

You can set up multiple keys on your AppLife Cloud account.

Pick one of the options and enable two-factor authentication on your AppLife Cloud account today. Doing so adds a significant level of protection for your AppLife enabled deployed applications.

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…