Packaging HTML5 help in an MSI installer

[SusanL]

We are converting our help from .CHM to HTML5. Our application is set up at our customers' businesses, and has both a Windows and a Web server component, so I will be creating help with and without Mark of the Web.

The developers are used to packaging the single file .CHM for the Windows client, and are suspecting that packaging all the files that go with HTML5 will be a headache, especially if the file names change. They are wondering if it would be better to install the help outside the MSI installer. I've tried to research this on the web, but am having problems finding an answer.

What is the best way to distribute HTML5 help in this sort of scenario?

[RamonS]

Could look into crafting a self-extracting archive that takes a destination parameter. The installer could then call that executable with the paramater based on the current install and extract the files to the specified destination. That way the installer only ever deals with one file and it should not be too difficult to keep that name the same.

[Nita Beck]

Ramon's solution is the exact one we use at one of my client's. We deliver the Help system in a self-extracting zip file to a staging area, where the devs who maintain the installer grab it from. The installer is programmed to extract the files and put them in the right place where the software application expects to find them for context-sensitive access.

[Paulie]

At my previous company we did something similar too. After the documentation build was completed, we ran a script that converted the HTML5 parent folder into a .zip file. This .zip file was then packaged into a .dll with a method to extract the help, and the dll was built into the master installer for the application. When a user installed the software on their local machine, the installation wizard called the method in the dll and the help was extracted.

The advantage of using a dll was that the method to extract the help was built into the archive containing the help. It meant that if we made changes to how the help should be extracted, old versions of the software would still support these changes. The other advantage was that the dll could contain a version number, so we could also do things like detect when a newer version of the help was available.