Over the last couple of days I updated Help Builder to support generation of HTML Help 2.0 output. Html Help 2.0 is a PITA and designed in such a way to be even less user friendly than the already screwy HTML 1.0 format. Yes there are some nice features in the format itself, but it amazes me how Microsoft could have made a process such as installing help as complex as this.

Generating the output for the Help 2.0 was not a big issue. The 2.0 Help Compiler is a bit less helpful than the 1.0 compiler in that it doesn’t automatically pull in related links the way the 1.0 compiler does. This means some extra work was required to parse all the source files on my end and pull in all related links like images and embedded href links. No big deal, but it seems silly that the compiler couldn’t take care of this. The end result of this process is that Help Builder now generates a fully self-contained HTML Help 2.0 project that you can open with the VS Help Integration Kit (VSHIK). Help Builder also compiles and locally registers the help collection so you can immediately preview it.

That was yesterday and after I had kind of put this off for a LONG time because the task seemed somewhat daunting it turned out to be a minor job to create the actual output and help file.

BUT – and there always is a but, HTML Help 2.0 files aren’t terribly useful on their own. For one the format isn’t really supported explicitly anywhere so there’s no easy way to plug HTML Help 2.0 into your own applications. Further more the Help 2.0 viewer is really not installed by default so you’d need to custom install it with your app, which really makes no sense. So the only real target for Help 2.0 is developer documentation in VS.NET.

This is where things get really sticky. Distribution of these freaking help files is ridiculously complex. First off help files need to be registered in order to be used at all. The excuse for this process is that you have a fixed name for the help file so it is not tied to a specific path on disk for identification. This is so that you link to other Help collections consistently without having to know the path.

Talking about DLL hell - for a Help File???? This is ridiculous <g>...

Manually or from within an app this process is easy, but from an installation this gets tricky. If you want to merge your Help 2.0 File into VS.NET this process gets ridiculously complex. You need to merge the help files by providing a merge ‘build file’ of sorts that describes exactly what you want to merge. Trying to register this stuff automatically is a major undertaking.

There are a few tools that help with this process which works fine for interactive installation, but for installs this is obviously not an option.

So now I’m wondering what should I provide here to make this process as easy as possible and ready to our customers who most likely want to plug there help files into VS.NET. Anybody out there who’s gone down this path before and want to provide some feedback on what you’d like to see?

For now Help Builder will generate the help content and the rest is left up to the developer in terms of figuring out how to integrate it into an install.