Tuesday, September 30, 2014

Challenges of Unit-Testing Installations

Every package author has reached the step where a package draft is built and tests are required to find and fix errors.
In many cases testing resolves to eye-check that files reside in the expected folders, and delegated on to QA team for product functional tests.

While most technologies and programming languages are packed with unit-testing frameworks, Windows Installer has none worthy that I encountered. WiX provide a very slim framework called Lux on which I will comment on my next post; however it offers little - if any - capabilities.

Indeed testing an installation package is difficult - files and folders being the easy part. Actually, all standard actions are the easy part as they're already tried and true.
Custom actions are where the problems begin: The basic idea of unit testing is that you can separate small units and test them out of context and independently to the rest of the code.
With installations this isn't true: unless executed by Windows Installer you can't get  valuable information and stimulation, such as built-in properties and execution privileges.

You could design your code in a way that separates input parsing from execution, and test the executing code alone. But even that can be inaccurate.
Examine for example a custom action that kills a process: You may code an immediate custom action to set CustomActionData to the name or ID of the process to kill, and a deferred custom action to kill it.
To test it you will could run the part of that kills the process. Test it with elevated privileges and the test passes; test it as part of an installation and the test fails - that's because Windows Installer - though running with LocalSystem account - runs without SeDebugPrivilege rights, thus can't kill a process.

It seems that installing the product is the only way to test it - same goes for upgrade, uninstall and rollback for each scenario.

In following posts I will expand my reluctance with Lux extension, and suggest a unit-testing framework for installations.

Tuesday, September 2, 2014

Authoring Very Large Installation Packages Using WiX

A while ago I was authoring an installation package for a customer.
The installation had abundance of files which I harvested using Heat.exe
When I got to running it an unfamiliar error message popped:


Or as it appeared in the log file:
2709: The specified Component name ('cmp8CD8B73AC8349972161D2AEAC3DDEE78') not found in Component table

Checking the MSI with Orca showed that the component was definitely present in the package.
Further investigation revealed an undocumented 65536 limit on component count - while  my customer's application had nearly 200,000 bitmap files.

After having thought of the issue for a while, I reached 3 alternatives to solving it:
  1. Splitting the installation to several products, each with no more than 65536 components
  2. Zipping the bitmaps into few archives and extracting them during setup
  3. Grouping multiple files into fewer components.
While all three alternatives are not perfect, the zipping option is quite outrageous. It generates modifications that Windows Installer isn't aware of, thus can't be rolled-back or un-installed properly.

The first option - splitting the installation to several products - was also cleared off the table due to inferior user experience.

That left me with grouping files into components as the best of imperfect options.
It does have pitfalls:
  1. It breaks component best-practices
  2. Files may be in-repairable since they are not key paths
Still, considering the product requirements and the alternatives, I decided on going with it.

Now... How was I to group 200,000 files into fewer components?
Having google'd that I concluded XSLT grouping using the Muenchian Method fitted just right.
With that I can group all the files within a directory to a single component. Since there were less than 65536 folders in my client's product, that was good enough for me.
I'll skip explaining the Muenchian Method itself since there's plenty of information about it on the web.

After implementing the grouping the installation passed perfectly.

I've assembled a project to demonstrate both issue and solution here.
To use the demo follow these steps:
  1. Download the code for wix-demo project
  2. Execute Grouping.bat to generate a folder hierarchy with 65550 files. 
  3. Build both projects - NoGrouping will produce the mentioned error, Grouping solves it.