Made My Day...

Kris, on the HATT list, really made my day.

---

From: Kris
Sent: Tuesday, September 29, 2009 10:45 AM
To: Me
Subject: RE: [HATT] How to update WebHelp embedded in .NET application?

Me,

Your response is spot on. We’re speaking exactly the same language. I’m going to follow up with the developer.

THANK YOU !!!

Kris

From: Me
Sent: Tuesday, September 29, 2009 10:05 AM
To: HATT@yahoogroups.com
Subject: RE: [HATT] How to update WebHelp embedded in .NET application?

While I use RoboHelp to generate WebHelp, I have had to deal with the same issue since I converted from WinHelp to HTML (WebHelp) that is installed on the user's C:\ drive. I'm not speaking specifically about .NET or Windows Installer - this is my experience with WebHelp and dealing with updated files.

We just cut the 10th release that has WebHelp for online Help.

At the beginning, the developer wanted a list of the files that had changed since the last update. So I started with your initial request below. In order to do this, I talked to our resident guru. He gave me an app called "Comparefolders.exe" that I use to compare the contents of folders. This app rocks. I'll check with my co-worker if he wrote the compare folders .exe file I use and if he did, whether I can share it, if you're interested. My process was to compare the output from the last update to the output for the to be released update. I would then send a list of the files that I had added or removed. This included .htm files as well as PDF files as well as .jpg or other graphic files.

My understanding is that he manually went in and made these changes. Again, I'm not specifically talking about .NET or the Windows Installer. However, my guess is that it's going to be the same type of thing - manually picking what files to add or remove. The list I gave him included the specific sub-directory as well so he would have to drill down and find them. My understanding is also that if you are looking at a directory with 100s of files, finding the 2 or 3 that changed among a list of similarly named files, is not very much fun.

However, we continued this trend until we were preparing a release that was very doc intensive. Lots of files were deleted or added. From that release to now, *my understanding* is that my co-worker thinks it is easier to simply replace the entire set of files than to pick and choose which specific files were updated. It still remains a labor intensive task, I think, because I hear grumbles occasionally about why we don't put our help on the website "like Microsoft does."

After the AM I've had, I refuse to go into that discussion today.

To bring it back to your concern about your users installing 115 MB each time, I used to think it would be a big time requirement and that only replacing specific files would reduce the amount of time to install our product. However, I don't have that opinion today. Help is always installed when our product is installed. My current Help directory is 111 MB (116,559,872 bytes) so it's slightly lower than your 115. I have 3,475 files in 6 folders.

My interpretation of your comment about not wanting to install 115 MB is that you think it will take a long time to install it. My hypothesis is that unless you have a significant amount of files that didn't change - say only 10 MB changed out of the 115 MB you quoted - you're not going to speed up your installation time by more than a few seconds. You will need to try this out, but perhaps you can get your developer to create a 'dummy' install for you that has all 115 MB as well as an install that has, say, 25 MB of Help. You should run time trials on PCs that your users likely have to see if the difference between the amount of files really makes a difference. Again, my hypothesis is that you will probably not see a big time dip. But these are your users, not mine, so you need to make sure this will work for you.

Like I said, I can check with my co-worker re: the comparefolders.exe file if it is something you think you need. I don't use it anymore because all my help files are replaced with each release.

Me

From: Kris
Sent: Tuesday, September 29, 2009 8:25 AM
To: HATT@yahoogroups.com
Subject: [HATT] How to update WebHelp embedded in .NET application?

Dear HATTers,

I've developed WebHelp using MadCap Flare for a .NET application developed
in VisualStudio. Please note that the WebHelp is embedded in the
application itself. This means that the Developer, who is using Windows
Installer, needs to add each of the 1500 files comprising the compiled help
into the install. This works like a charm (though it's a little labor
intensive for the developer).

The problem is that we want to update the WebHelp for a revision. This
gives us two choices:

- Manually replace 1500 files from the existing install to the revision
install and ask our customers to install 115 MB each time (ouch!)
- Identify the changed files and replace only those files in the install.
This is, of course, what we would like to do!

Unfortunately, when Flare compiles the WebHelp, it replaces ALL the files
and applies new time stamps to them (whether they've changed or not). So
while we can identify the updated topic files by looking at the Date
Modified value in Windows Explorer, there is no way to identify all the
other files, including "index chunk" files (the number of which changes when
you add new index entries) and others, that have been updated as the result
of the new compile.

Does anyone have a fix for this? Do any of you update WebHelp with Windows
Installer? If so, how do you handle revisions? (Any other suggestions?)

Thanks,

Kris