Why you need to take notice of the .APPX installer framework

At Build 2015 in March, Andrew Clinick said: “APPX is now our deployment model. MSI isn’t going to go away, but we want you to move to APPX. We’re investing all of our efforts into making AppX the ultimate installer across the Windows ecosystem.” At build 2015 however Windows Phone was still being discussed along with “Continuum” (the idea that your phone can be a PC in your pocket) and UWP Apps (which only come in APPX format) were important for Windows Phone. Come build 2016, Windows Phone was missing and many people now regard it as dead.

In May we heard about Appinstaller (with Windows 10 Anniversary Update) allowing you to install an .appx file by double clicking on it.

There has been recent news about Desktop Bridge and the Desktop App Converter. This is about making it easy/easier to move/shoehorn existing apps on to the .APPX model (but not making them UWP Apps). This news was fairly low key and I didn’t find the benefit arguments given too compelling for a corporate environment (Live tiles, Notifications, Cortana Integration, Re-installation of your apps after a broken PC), but there are productivity and admin reduction advantages to self-service app-stores, particularly for apps where licensing is not an issue and admin rights are not required.

For Nano Server, the news is that .APPX is the deployment framework and .MSI has been excluded:  See “Installing Windows Server Apps on Nano Server“. So it appears Andrew is still at work and APPX is still considered to have advantages over the .MSI model.

So the underlying message here for us .MSI Packagers is that although things have gone very quiet on Windows Phone and the Windows Store hasn’t taken off yet we are still going to have to take notice of the .APPX format. The good news (announced at the same Desktop Bridge session) is that the format is now supported by both Advanced installer and Installshield.

To throw in a final titbit, did you know that packages created with the Desktop App Converter use the same techniques as App-V and seemingly you can even use the SDK Tool MakeAppX.exe to Pack & Unpack App-V 5.0 Files.

Advertisements

Advanced Installer Evaluation

A few months ago I carried out an evaluation of Advanced Installer from Caphyon in comparison with InstallShield and decided I should share this on my Blog for the benefit of anyone else who may be trying to choose an MSI Packaging tool as I couldn’t find many other people offering reviews:

1.1         General

Advanced Installer uses a similar 3 pane view to Installshield with main areas of functionality listed down the left hand side. This view can be easily customised to only include features you use (e.g. I removed Game explorer). The screenshot view below has been customised to just show the most relevant features. You will notice there is no shortcuts option, shortcuts are found in the relevant folder(s) in the Files & Folders view.

image2

Note: Advanced Installer also includes the ability to create build & edit projects from the command line.

Unusually each and every resource including individual registry values is given it’s own component and the approach to COM data is radically different to Installshild. There is a section in the interface dedicated to COM where the various properties are displayed as fields on a form (with drop down lists where relevant for allowable values), but the COM tables do not get populated in the MSI it produces, except for a single field in the PROGID table.

Limitations: Apart from the minor inconvenience of locating shortcuts manually, the one resource per component approach will impact on performance. e.g. Target registry overhead will be greater and Installs/Uninstalls will be slower on larger packages (I did not have opportunity to run further tests to quantify this).

Transforms

Normal transform functionality is supported, although support for multiple transforms appears to be limited to during the creation of a response transform, at which point you can specify multiple additional transforms to include. The transform differences are not displayed by default in the table view. I suspect this is for performance reasons.

It is possible to merge a transform into an .MSI via file save as.
A transform can be created from the differences between 2 .MSI files.

New:

  • A nice feature about response transform creation is that on completion you are immediately shown the properties that have been created/set.
  • When transform differences are displayed you have the option to revert any rows to their original setting(s).

Limitations: Cannot display the combined result from multiple transforms. Cannot merge transforms other than during creation of a response transform.

Alternatives: Insted has excellent transform support. Orca is also available.

Custom Actions

Equivalent functionality appears to be available for custom actions although the range of predefined custom action types is greater.

New:

  • A much wider range of pre-defined custom action types is provided, including things like Run Powershell script (for which they have their own launcher .dll), detect service, stop service, detect if a user exists, Test ODBC connection etc.
  • Selecting where in the sequence to run your action has been made more straightforward and a range of predefined conditions can be selected from a list in a condition builder dialog. e.g. AI_DETECTED_JRE_VERSION >= “1.7”, AI_DETECTED_INTERNET_CONNECTION. The “AI_DETECTED” relates to custom Advanced Installer functionality implemented by their own .DLLs.
  • Custom Actions can be copied to another project via copy and paste.

Manipulating the Registry

Each registry key is added to it’s own component by the repackager so there is no concept here of moving registry out of the bucket components into a component associated with the owning file. Import of .REG files is available.

Registry components each have a KeyPath registered that is an offset to another registry component of +37 so component __1012 has a KeyPath of __1049 so all the registry entries appears to be chained together.

Limitations:

  • It isn’t possible to directly export registry keys, although you could work round this by using the MSI diff capability: Generate 2 MSIs, one with the required registry keys deleted and use MSI diff to generatate a transform containing the keys. To get a .REG file out however might require an old copy of InstallShield. NB It should be noted you can copy and paste registry from one project to another. I’m told that adding registry export capability is planned for a new release. (update: export capability has been added in Version 13.3)
  • It isn’t possible to drag n drop registry keys from the registry on the host PC into the package although in my experience this functionality is not typically used by repackagers.
  • Limited use is made of the COM tables with CLASS not being populated at all and a much smaller number of entries in the PROGID table than in a comparison InstallShield capture. I suspect this is related to the Caphyon design choice (as above) of one component for each resource rather than the more common approach of linking a COM .DLL with it’s associated advertising registry in the same component. This generates ICE33 warnings, but ICE33 appears to be considered obsolete by Microsoft https://msdn.microsoft.com/en-us/library/aa368957(v=vs.85).aspx Presumably however this would affect self-repair such that for example if you had a package without an advertised shortcut which was launched via a file type or MIME type association and you were relying on self-repair to create some HKCU registry keys in the logged on user’s profile, this would fail.
  • I could not see an option to extract COM data from a file included in your project. COM registry would normally be captured during repackaging anyway but this is not always the case. Another area where this functionality can be useful, is for identifying which component bucket registry belongs to, but this would appear to be irrelavent with the Advance Installer approach.
  • The way registry entries are chained together led to numerous ICE69 warnings in my test package. Deleting some registry keys to simulate junk cleaning, appeared to confirm this leads to a loss of referential integrity, as you now have component(s) with a missing KeyPath(s).

Alternatives: Wisecomcapture.exe can be used to extract COM registry into a .REG file which could be imported.

Manipulating Files

Text file manipulation is provided in the form of Append/Overwrite and find & replace. Regular expressions can be used for finding text. It is also possible to add variables say to an .INI file and replace these with properties specified at install time. A tick box is provided to enable the existing fle to be backed up before making changes.

Limitations: XML Files can be created but the functionality doesn’t seem to be as rich as Installshield (although I have never used this).

Repackager

Repackager is incorporated into the main application’s functionality rather than being separate as it is with InstallShield and turn’s the approach to using Virtual Machine’s on it’s head by allowing you to nominate the VM and specific snapshot to be used for the capture and controlling the process externally (a bit like the way AppDNA works) rather than lauching repackaging from within the VM. Exclusions can be configured as part of the process flow before the capture begins. This process I found to be a bit problematic, with VMware, but didn’t have time to explore it fully. I got it to work with a snapshot that was suspended while logged onto the account specified and the network connection set to bridged, but in this configuration you would get a UAC prompt saying that the machine was on a different network – possibly due to the VM being in a workgroup. I did not get it to work fully with any of the other networking options, but didn’t have time to follow up with the vendor.

image3

Hyper-V is an alternative VM option that I didn’t try, but as it is a Type 1 Hypervisor (bare metal) as opposed to Type 2 (Hosted) like VMware workstation I’m not sure if this would work on the same PC or if using Hyper-V with Advanced Installer would require you to connect to a HyperV instance on a server.

There is no separate junk cleaning step at the end of the capture stage as you would have with InstallShield Repackager before generating the .ISM, all editing happens within the main editor. This isn’t really much of a loss, it simplifies the workflow, but does mean you can’t go back to your original capture if you remove something by mistake. Having said this, there appeared to be issues with junk-cleaning registry later in the process, because of the way KeyPaths are allocated – as mentioned in the Registry section above.

One slight issue I experienced at the build stage was an error reporting that it could not find a file from C:\Windows\System32\config – this location is secured so the file could not be copied out & probably shouldn’t have been included anyway.

The capture approach seems to be a combination of single step snapshot & installation monitoring although there is a tick box to disable the latter.

Limitations:

Several times I found that building the resulting project failed because files that should have been excluded could not be located. This could probably be resolved by simply updating the folder exclusions list. On another occasion the build choked on a scheduled task it had captured (throwing an .MSI API error) and I had to exclude it from the project. Note: InstallShield Repackager did not pick up this scheduled task at all.

New:

  • If a default install is required, you can ask Advanced Installer to automate the GUI Accept License agreement, Next, Next etc steps through the installer for you.
  • A “System Noise Recording” can be carried out before the capture begins to help minimise Junk Cleaning. A previously saved “noise” recording can also be used.

System Search

The System Search functionality appears to be broadly similar to InstallShield.

Launch Conditions

Extensive launch condition capability is provided.

Features

Features can be added nested and shared with multiple features. Components are added to a feature via drag & drop.

Condidions

An advanced condition builder is provided with a wide range of pre-defined conditions available, making the need to remember condition syntax largely a thing of the past.

ICE Validation

ICE Validation is supported as part of the build sequence, but cannot be run on it’s own No .CUB files are included with the software and manual configuration is required to enable this functionality and specify the path to the .CUB file you wish to use. The documentation recommends you install the most recent version of msival2 from the Windows SDK.

New: Probably the most important thing to say about ICE validation is that after the build is completed and the list of errors is displayed, automatic fixes can be applied for many issues on an individual basis or by selecting a group of errors. This is a useful time-saver and eliminates human error.

Note: The actual ICE number is not shown in the list of errors at this point although it is included in a log window during the build.

Alternatives: Both Insted and Orca support ICE validation

Conversion of InstallScript Packages

InstallShield includes additional functionality to support the conversion of InstallScript Packages. This technology would not be available to Caphyon as Installscript comes from the same Flexera stable as InstallShield, but I suspect this functionality is little used anyway.

Alternatives:
Scripted install.

Merge Modules

It appears Merge Modules are not supplied out of the box, but can be added from sources such as Visual Studio.  In practice Microsoft appear in recent years to have stepped back from creating new merge modules other than for Visual C++.

Summary/Conclusions

After using InstallShield for a long time, Advanced Installer is a breath of fresh air. Although it uses a similar 3 pane layout to InstallShield, it feels much more modern and assumes less background knowledge on the part of the Packager. Some Windows Installer features that are obscure with Installshield (to the point that few would use them) are placed front & centre in Advanced Installer and prompt the user to consider a more advanced approach, implemented with point & click ease.

Caphyon deliver regular updates to the product and the company has a good reputation for support.

Performance in use is excellent and should improve repackaging times, although as noted the one component per resource approach will have some impact on time to install for large packages. Issues that prevent an unreserved recommendation to purchase and that may require further analysis and testing are:

  • The impact of registry KeyPath chaining.
  • The implications of reduced use of the COM tables.
  • The repackaging problems experienced with VMware although it’s possible the Hyper-V option may be a good alternative.

In the final analysis it must be noted that the core InstallShield interface/approach has hardly changed in years and Advanced Installer, despite one or two rough edges achieves the unexpected victory of making InstallShield look something of a dinosaur by comparison.

Note: This review was carried out using version 12.5. Caphyon have made various changes to the product since. I have included a link to the version history below.

Useful Links:

Advanced Installer features by edition
Advanced Installer features
Advanced Installer version history
2015 Review
2013 Short Review

Advanced Installer download page