CubMakr – Version 2 BETA Release

Last week we released CubMakr V2, with a few new features.  You can find a quick video here.

One of the new features was simply being able to specify custom ICE references as opposed to all the ICE messages appearing as ALKANEICE01.  This was a request from Rory over at Rorymon.com.This can now be specified when you’re creating a new rule, at the very top:

ice_nameIf you’ve already created your rules you can edit each rule and change the name accordingly.  This is useful so that you can refer to specific ICE messages like you can with normal MSI validation (ICE33, ICE03 etc).  It also means you can set up a web page with references to your custom ICE messages and instructions on how they can be resolved.  Unfortunately, the HelpURL part of the ICE message no longer appears to be supported by most products so we can’t include this in the CubMakr toolset (sad face).

The second new feature in Version 2 is Advanced Scripting.  This is really interesting, as it enables advanced users to include their own custom VBScripts into the cub files.  These scripts can be used to perform custom ICE routines (which cannot be handled by CubMakr natively, such as detecting empty components) and even integrate with your own application tracking tools for real-time validation!!  The scripts can be sequenced to run before the CubMakr rules, or after the CubMakr rules.  An example of advanced scripting can be found here.

advanced_scripting

CubMakr – Advanced Scripting Example

I thought I’d give a quick example of how advanced users can utilise advanced scripting in CubMakr.

Example 1: Integrating with your Application Tracker

The first example I want to show is how we can integrate the CubMakr with your in-house tracking tool.  Some places use Sharepoint to track applications, some places use a SQL Server back-end (ok…so does Sharepoint….but I believe the preferred approach for querying Sharepoint is to use CAML and you can find a VBScript example on my blog here).

I’ll let you read the commented code to see what the script does, but basically:

  • In order to link your package to your tracker record, you’ll need a reference.  In this example I create a property in the MSI called ALKANEREF and set the value to the unique reference for my package.
  • In the script, I read the value of ALKANEREF and then query the SQL Server database to retrieve various records (vendor, application and version).
  • I then create a session property (i.e, not a property which will persist in my database) called ALKANEMANUFACTURER which we can then use as part of a CubMakr rule to validate (for example) the Manufacturer property value.

Because we want to set the ALKANEMANUFACTURER property before the CubMakr rules are run, we would obviously set this script to run before the CubMakr rules.  Here’s the script:

Example 2: Writing your own ICE routines

The second example I wanted to show you was writing your own custom ICE routines.  CubMakr is used to provide a simplified way of checking for certain entries within the windows installer tables and summary information stream.  It cannot handle more complex scenarios, such as checking for empty component, checking for duplicate registry entries etc.  For these scenarios there is now the facility to add your own custom ICE routines.  Here is an example of some custom ICE routines:

 

 

CubMakr Detection Examples

This page takes us through some quick examples of CubMakr detection examples. It includes examples using different search methods (‘equals’,’starts with’,’contains’,’regular expression’), resolving proerties, performing case-sensitive searches and using conditions.

 

Example 1:  Perform a case-sensitive search for a property name.  If property/value is missing, display a warning message.
Check:  Check that the ALLUSERS property is set to 1.

Check for ALLUSERS property

 

 

 

 

 

 

Example 2: Use the ‘contains’ comparison and flag for modification.
Check: Check the the Value column of the Registry table does not contain hard-coded paths.

registry_hardcoded

 

 

 

 

 

Example 3: Use the ‘equals’ comparison and flag for removal.
Check: Check the TNSNames.ora is not in the package (Files such as this are usually managed outside the package).

file_filename

 

 

 

 

 

Example 4: Use the ‘starts with’ comparison.
Check: Check that services use the ServiceInstall/ServiceControl tables, and not the registry.

registry_registry

 

 

 

 

 

 

Example 5: Use a case-sensitive regular expressions to check for the presence of multiple values.
Check: Use a regular expression to ensure that the COMPANYNAME property is one of our supported clients.

property_companyname

 

 

 

 

 

 

tipTip:  Use the following regular expression examples to construct your own searches.

 

Starts with: ^searchstringEnds with: searchstring$

Contains: searchstring

Equals: ^searchstring$

 

Example 6: Use the ‘Resolve properties’ setting to resolve a property value.
Check: Check that the Summary Information Stream Title value is the same as the ProductName property value.

sis_title

 

 

 

 

Example 7: Use a condition for the validation rule.
Check: Check that a launch condition is set.  Add a condition specifying that this rule is only valid when validating packages targeted at Windows 7 platforms.

launchcondition_condition

CubMakr – Simplified and Centralised Online Cub File Creation

Link to tool: CubMakr – Simplified and Centralised Online Cub File Creation

Link to video demonstration: CubMakr Video

Link to examples: CubMakr Examples

Link to V2 Updates: CubMakr V2 BETA Release

Link to video demonstration for V2: CubMakr V2 Video

When creating MSI packages we should always ensure that they conform to Windows logo standards and best practises. Adhering to these standards enables us to produce more reliable and well-authored MSI packages.

To perform this compliance check, we usually validate our MSIs using the Full MSI Validation Suite. What this validation process does is validate the MSI tables against certain rules which are specified in a .cub file called darice.cub. As a result of running this validation, we may be prompted with ICE warnings/errors which we should attempt (in most cases) to resolve.

This validation is great, but what if we need to do our own custom validation? For example, Alkane Solutions do work for multiple clients who all have different requirements:

Customer-specific values, such as Properties:
COMPANYNAME (“Customer 1”, “Customer 2” etc)
ARPNOREMOVE (Some like 1, others like 0)
REBOOT (Maybe we just want to ensure that this property exists, and that it is set correctly?)
Customer-specific logic, such as Custom Actions:
Some of our clients use Custom Actions to perform certain logic, and we must ensure that these are present in every package we deliver. 

Customer-specific naming conventions:
Some of our clients use specific naming conventions for things like the ProductName property. Some like to limit the number of periods in the ProductVersion.

In-house validation checks:
We like to check that our tables do not contain hard-coded paths, that we only append to (and not overwrite) the Path environment variable, that services use the ServiceInstall/ServiceControl tables and not the registry table, and that TNSNames.ora is not included with any package.

 

But how can we perform these validation checks when we have no scripting knowledge, and no knowledge of .cub files?

Easy – that’s where CubMakr comes in.

CubMakr is a custom toolset written using the Wix DTF (Deployment Tools Foundation) with the aim of generating custom CUB files to validate your MSI packages.  No scripting knowledge is required!!  CubMakr should be used to generate a CUB file which reflects the packaging standards that your company/client adheres to.  Using it will:

  1. Increase Accuracy of Packages
  2. Reduce Errors
  3. Improve Quality and Reliability
  4. Reduce Packaging Time

Here are a list of features:

  • Validate ANY table, and ANY column
  • Validate the Summary Information Stream
  • Multiple search comparison operators such as ‘equals’, ‘contains’, ‘starts with’ and ‘end with’
  • Search using regular expressions!
  • Perform case-sensitive searches!
  • Resolve property names at validation time
  • Display custom messages!
  • Set conditions for each validation rule!
  • Display warning, error, info or failure ICE messages!
  • Re-order the rules you create, so messages are displayed in a specific order!

and here is an example of things that can be validated for:

  • Check that certain values exist – this could be a property/value pair, a registry key, a launch condition, a custom action….or anything else contained within a Windows Installer
  • Check the format of an entry is correct – for example, check that the ProductVersion property is of the form major.minor.build
  • Check for hard-coded paths
  • Check that the case of an entry is correct – for example, check that GUIDs are upper case and check that specific public properties are upper case
  • Check that files exist/don’t exist – for example, ensure that files such as TNSNames.ora/hosts/services are not captured.
  • Check that services use the ServiceInstall/ServiceControl tables instead of the Registry table (where possible)
  • Detect if a driver installation has been captured, and warn the user that it must be configured accordingly
  • Detect for darwin descriptors
  • Detect for junk files/registry which needs excluding
  • and much, much more…

Since the first release is just a BETA (to see if people find it useful), we have not included a way of saving cub files and retrieving them at a later date.  Unfortunately whatever cubs you generate are only persistent for the current browsing session.  The long term goal would be to enable people to save cubs for each client/project.

Example rules can be found here to get you started: CubMakr Detection Examples

Hopefully somebody will find this useful.  If you do, please feel free to comment.