Getting Started with Xafari Application Starter

Basic Terms

Source

A remote (network) storage from which the application is copied.

Version / Configuration

A complete set of the application files (libraries, files for execution, and any other component required to provide the correct functioning of the application).

Version / Configuration optimization

A process of optimizing the code by means of the ngen.exe utility.

Predefined list

A list of the application versions stored in the root folder of the utility as an .xml file.

Version / Configuration deployment

An act of copying the application files from a remote database to the user’s workstation

Getting started. Adding versions

The AppStarter utility is used to simplify the process of installing appropriate versions of the applications to the user machines. It also provides an easy way to update and optimize the applications with minimal manual involvement.

By default, all AppStarter files are stored in the following folder of the Xafari framework: ...\Galaktika\Xafari Framework vXX.X.XXXX\Tools\AppStarter

In the current AppStarter edition, all versions for further deployment are expected to be stored on the network drive. The name of the version folder should reflect the exact number of the application version that is stored inside.

To add a new version to the list, click the Add button. In the pop-up window, fill the required fields (Path, Caption, ID).

By default, the Caption field value is set to be the last folder in the file path. However, the users can change this value at their own will. The ID field also gets its value automatically upon GUID (see the figure below).

appstarter_2

When adding a new version, the user can replace the autogenerated GUID with any other unique identifier. The name of the local copy of the version will match the value found in the ID field. The operating system should be able to create the folder which name matches the mentioned ID. The ID should be unique for each version; otherwise, the user will be unable to start the application.

The Path field should contain the full path to the version and can be filled manually or via the Browse button. In the path, the folder with the exact application name (for example, MainDemo or FeatureCenter) should be present.

In the version folder, each release is stored in a separate folder. There can be lots of version folders inside the application folder. The version folder stores a particular release of the application that may be different from other releases. The names of these folders should always correspond to the following sample: V<version number> (for instance, V1.2.2.1504).

The folder with the version’s number contains all libraries and other files required to launch the application. Also, it has the Package.xml file that stores metadata. For a remote version, this file has the Start File field (the relative path to the executing file) and Start File Arguments (the list of parameters for the executing file). The Start File field should always contain the appropriate value; the Start File Arguments field can be empty. The sample for typical metadata content of the Package.xml file can be found below:

  • xml

<?xml version="1.0" encoding="utf-8"?>
 <ConfigurationList>
  <ConfigurationItem>
     <StartFile>Xafari.FeatureCenter.Win.App.exe</StartFile>
  </ConfigurationItem>
 </ConfigurationList>

As soon as the version was added into the list, it can be run by clicking the Start button in the main window of the AppStarter tool. If the local copy is absent or its version is not the same as in the source, the update is launched prior to starting the app. AppStarter never starts the application that is not completely identical to the version found in the remote source.

Changing and removing versions

To modify the list of versions, use the Edit and Delete buttons.

The Edit button displays the window, in which the user can leave the autogenerated values or specify the path to a different version. There are two fields (Path and Caption), as shown in the figure below.

appstarter_8

By default, these two fields have the values of the previously selected version. The ID field is absent and, therefore, cannot be modified.

When clicking the Delete button, the deletion approval pop-up window appears. If the user approves, the version is deleted from the list along with its local copy and the desktop icon (in case there are any).

Local configuration copy; how to create, update, and launch

The local copy of the application's version is created via the Update or Start button.

By default, each local copy of the version (configuration) is stored in the personal user folder: C:\Users\<username>\AppData\Roaming\AppStarter\Configurations\<version ID>.

When the Update button is clicked, AppStarter compares the local copy of the version (if it was previously installed) and the network source.

If the versions are different, AppStarter replaces the local copy with the version found in the remote source. The replacement process is visualized in the UI as a progress bar. The user can also see the name and the relative path of the file being currently copied, the time spent, and the time remained. If the user cancels the update, there will be no functioning local copy of the version.

If the user has the latest version when clicking the Update button, then the pop-up window appears (see the image below).

appstarter_5

Clicking OK leads to replacing the local copy with the version from the remote source.

AppStarter also searches for any mentioning of the file for execution in the metadata file (Package.xml). In case no data is found in Package.xml or the specified file is absent, then the error message is displayed (see the figure below).

appstarter_6

Until the source version is free of issues, it is not possible to access the application through AppStarter even if there is a local copy on the user’s local drive. By default, the updated version is supposed to have a new version of the database; thus, the old version of the application is locked until being updated.

appstarter_7

Before updating, the system also checks for the presence of the executed file in the source. In case the file is absent, the update does not run. Due to inactivation of the local copy, the user should contact the administrator.

Removing unused versions

The removal mode is utilized when the local folder of the user contains several earlier versions of the application, but they are not included in the list anymore. To remove all unused local copies of the application, open the Tools menu from the AppStarter toolbar and click the Cleanup button. It will remove all unused local copies from the folder utilized by AppStarter.

Remote source version updating

Different versions of the remotely stored applications are in the folders with the appropriate titles (see the picture below).

appstarter_9

This image demonstrates the folders containing different versions of a sample application. To update the version of a remotely stored application, create a folder for the upcoming version and put the updated application there. AppStarter will find the latest version based on the name of the folder. However, the folder should contain the Package.xml file that is required by AppStarter for correct functioning.

In the image above, the version should be updated as follows:

  1. The administrator creates the folder for the new version and names it at least “V2.0.1.0896”.
  2. The administrator places the updated application to the source folder.

When the update of the remote (network) version is finished, the Package.xml file should be placed into the new version’s folder. Until it is done, AppStarter ignores the folder with this version.

The role of Configurations.xml

The list of the current versions is stored in the Configurations.xml file that is created automatically and can be found in the AppStarter folder bound to the user's Windows account: C:\Users\<username>\AppData\Roaming\AppStarter\Configurations. Therefore, each particular local account has its own Configurations.xml file and the unique list of versions in that file. The Configurations.xml file has several fields: ID, Name, and Path. These fields store the data about a certain version: its unique identifier, the name, and the path. The example of the Configurations.xml file can be found below:

  • xml

<?xml version="1.0" standalone="yes"?>
 <ConfigurationsDataSet xmlns="http://tempuri.org/ConfigurationsDataSet.xsd">
  <Configurations>
     <ID>96e032e1-3d5b-4471-8331-3ea92a222308</ID>
     <Caption>FeatureCenter</Caption>
     <Path>C:\XafariApps\FeatureCenter</Path>
  </Configurations>
  <Configurations>
     <ID>94440bb4-d186-4440-949f-38e3e1f001b7</ID>
     <Caption>MainDemo</Caption>
     <Path>C:\XafariApps\MainDemo</Path>
  </Configurations>
 </ConfigurationsDataSet>

The user can see the name and the number of the version, plus the optimization info. The number is displayed when the special user folder contains a local copy of the version that can be run. In case there is no local copy of the version on the user’s physical drive, the number is not shown.