Compiling DotNetHelp into a single file

[ScottWolter]

Good Evening,

Can DotNetHelp be compiled, or published, into a single file? I read somewhere all my content could be distributed as a single file but I cannot figure out how to do this.

Thanks,
Scott

WinXP Pro SP2
Evaluating Flare 3.1
Office 2007 Ultimate

[SteveS]

Hi Scott,

Just in case - welcome to the forums.

You have 2 options for single file distribution - printed (pdf/Word) or "compiled" html (chm).

DotNet help does have an internal directory structure.

[Roostar2004]

Is this somthing that will be added in the next release of Flare? I could see the sercurity purpose for this as it is much easier to keep one file secure then 100

[Richard Ferrell]

Currently with Dot Net help is it not a compressed file, Only HTML help is a compressed file. I will add this as a feature suggestion.

[RamonS]

Is this somthing that will be added in the next release of Flare? I could see the sercurity purpose for this as it is much easier to keep one file secure then 100

Why would that be easier? And why do you want to 'secure' the help anyway?

[BruceMcNaughton]

Hi,

I'm glad to see this raised again. I believe I submitted this as a feature request a while ago.

Given the nice layout and more secure interface (not like the CHM), a compressed set of files (possibly encrypted) would make the reader a good tool for publishing content that might be sold separately. Having all of the files uncompressed and individually visible - makes this a bit more difficult. Also version control is a bit easier with a single file rather than multiple files.

some thoughts..

Regards,
Bruce

[RamonS]

I see the benefits of a single file, but encryption so that it can be sold? Since when does one want to sell a help file? Why go through all this effort if one can simply take a screen shot of the topics and distribute the images or even easier, copy and paste the text in a document or a new, unencrypted help file? Besides that, none of the DotNet applications that I've seen so far come in a single file. There are dozens of files scattered across the system. If it is about securing something I'd worry about the application first and not about the help file.

[BruceMcNaughton]

Hi,

Maybe there are things other than help files where these tools can be of benefit! I'm looking forward to new features (one can hope) in V4!

Regards,
Bruce

[KevinDAmery]

Sounds to me like you want an alternative to PDF.

[LTinker68]

Maybe there are things other than help files where these tools can be of benefit!

I'm kind of thinking of that currently, myself. I've been asked to create a user manual as well as a training guide. The online training guide they want in Powerpoint or something similar (for instructor presentation), with the printouts to have the same layout/look of the online version so that the trainees can follow along. It would be great if the DotNet Help were a flat/single file. If it were, then I could just give them that and set up the skin for that output to be the way I want, although the transition from page to page wouldn't be as smooth or fancy as it is in Powerpoint, unless I want to add some Javascript.

Anyway, I'd also like the DotNet Help to be a single output file.

[JasonSTI]

I agree, and have made this suggestion as well. We are currently stuck with HTML Help for our help distribution, due to Vista compliance and version control necessity, but would gladly update to DotNet Help if it was compiled into a single file. It is just too hard to do version control for hundreds or (in our case) thousands of HTML files...

[LTinker68]

It is just too hard to do version control for hundreds or (in our case) thousands of HTML files...

Just out of curiosity... Why would you want to do version control on the output? Why not on the "raw" source pages, since you'll only be checking in/out the files that actually change. If you do version control on the output, then yes, each and every file would be considered changed because the build date of all of them would change from the previous build. And if you do that and don't make any changes to TopicA in the last 10 builds, for example, then if you wanted to compare its current version to its previous version, then you'd have to go back 11 builds. Whereas if you just version controlled (is that a verb?) the source files, then you'd only have to go back one step.

[JasonSTI]

I'm referring to version control on our installation program, not on the source control in Flare.

Our data files and main installation programs are installed on a single server, and a client set of programs, help files, etc are installed on the workstation. When the program runs on the workstation, it checks for updated files on the server, and copies them down if they have been updated. Copying seven CHM files is fine; copying hundreds of HTML files is not. If DotNet was a single file, we could use this instead.

[KevinDAmery]

Just thinking out of the box for a bit, can your developers modify the process so that it compresses all of the files that need to be transferred (into a zip or other archive format) then uncompresses and deploys them at the customer's end? This could get around the problem, plus it may reduce the overall amount of data customers have to download.

HTH.

[JasonSTI]

That was our original thought, but the size of the program files, help files, multimedia, etc, makes it so updating all of the files at once problematic (it could take 20-30 minutes if a user only has a 10MB LAN with lots of traffic). We are currently creating an index on the workstation that collects "version" information for each program and help file, and if they are not the same as what is on the server, they are updated the next time the program is run. So we need to be able to pick out just what needs to be updated, instead of updating everything each time.

We could easily create a compressed help project for each, and extract it on the workstation, but our dev manager said he would prefer a single-file solution instead of cluttering up the workstation with HTML files. So for now, we are using CHM.

[RamonS]

But when you are concerned about the amount of data to transfer to clients and only want to send over what really changed, isn't it then better to have many files instead of everything bunched up in one big fat file? With separate files you need to exchange maybe only a few files when a few topics changed. If you have one big help file you always have to push that down no matter how small the change was.
Unless I misunderstand, but it strikes me as if your arguments make a compelling reason for not compiling the help into one file.

[KevinDAmery]

That was my take on it, too. As long as you over-write the existing .htm file instead of appending it somewhere, it wouldn't clutter the system up. (And yeah, there's a lot of files, but nowhere near as many as, say, the exes and dlls Microsoft throws into the install directories for their applications

[nsemple]

We, too, would love it if you could provide DotNet Help so that it was distributable as a single file (like a chm file) rather than having to provide content with directories of files. We need the ability for customers to view our Help which is stored on a server rather than on the client computer. We used to be able to do this with chm files and now because of security restrictions with the Microsoft viewer can no longer do so.

We are using Flare and have been struggling with WebHelp output and have run into countless issues as we try to integrate our Help projects into our development's build process. Restrictions on path length as they pull our files into their Synergy build structure, and so on. Issues are piling on as our development team tries to deal with the tens of thousands of files coming their way rather than with the handful of chm files they used to get.

We have made this enhancement request for DotNet Help output to be a single file many releases ago. PLEASE, PLEASE, PLEASE consider providing this option for your Flare customers...

[lbeu]

Our software engineers have pointed out to a problem during installing and uninstalling of our main software application together with the online-help (created and generated with Flare). It is the tremendous amount of files which is created during compiling of the DotNet help.

The user language of our main software application (inclusive the online help) can be chosen out of 14 languages. Therefore the installation of the online help contains all of our 14 foreign languages what results in an amount of more than 35000 single files. Due to this amount of files the installation/de-installation of our application (especially of the online help) can take more than half an hour - and this on each computer.

So is there advancement from your side in one of the upcoming releases of Flare to pack (to zip) the content folder of the DotNet help in a ‘container´ (i.e. zip file) and with the possibility to unpack in real-time the requested htm file?

Packing/zipping the files in this way would also create a new kind of standard regarding ‘packed online help’. Up to now only the obsolete CHM format exists.

Best regards

Udo

[adlangx]

In order to deal with the large size and number of files we zipped them up and unzipped them programatically.

The files live on the server in a zipped package. When the client asks for the package we send it down (it shrinks down quite a bit so the download is fast as long as you have a solid intranet). Then we have code on the client that begins unzipping the files into the proper directories in the background.

It takes about 2-3 minutes for the files to unpack, but the user doesn't see it unless they try and open help while it is installing. In that case we just pop up a message telling them that help is being configured and to wait a few minutes to try again.

It was the best way that we could find to move 100MB of files down to the client.

[Andrew Heard]

Hundreds of files - how is this different from WebHelp?

Seems like a lot of people want a configurable HTML chm.

[BruceMcNaughton]

Hi,

The idea of using DotNetHelp as a replacement for a CHM is the goal or vision ... where the local help for an application looks like the online help over the net. I find the big issue with number of files is due to the windows installer packages and the ability to do updates to software applications. Some packages that build windows installer packages (MSI) like to see files in a component to be able to manage each file ... some require that each file be uniquely identified ... maintenance of all of the file references becomes difficult and installation time increases as each file requies a bit of checking.

Accessing all of the files through a ZIP file means only one file needs to be installed and managed on a local system. ZIP files do not have the same security problems as CHM files.

There has been some discussion about HELP3 which (I believe) includes a ZIP file structure (rather than a chm) for storing and accessing the files. Help3 was supposed to be available as part of the latest Visual Studio.

I have not been following HELP3 development recently ... however, from what I've read ... this zip file approach would meet my needs... however, I'd like a DotNetHelp look and feel to match webhelp.

FWIW... (this has been discussed a long time...?)

[RamonS]

As far as I know Help3 is used as help platform for VS itself, but it is not a format officially released to the public. As it stands right now, Microsoft continues to recommend using CHM. Some have re-engineered that format, but I do not know how well that worked out.

[LTinker68]

The DotNetHelp has a single, standalone viewer like CHM, but multiple files like WebHelp. And unlike CHM, it can be viewed over a network. And like CHM it needs a dedicated viewer -- it's just that CHM's viewer is installed with Windows and DotNetHelp's viewer has to be downloaded by the user or distributed with the help.

DotNetHelp also has an SDK for embedding the help in .NET applications, like Flare's own help does. I have a feeling that's the bigger selling point in MadCap's opinion, since they haven't put any time to really modifying the DotNetHelp standalone output so its skin can be modified like WebHelp's skin.

[BruceMcNaughton]

Re: DotNetHelp?

The DotNetHelp has a single, standalone viewer like CHM, but multiple files like WebHelp. And unlike CHM, it can be viewed over a network. And like CHM it needs a dedicated viewer -- it's just that CHM's viewer is installed with Windows and DotNetHelp's viewer has to be downloaded by the user or distributed with the help.

Are you saying that the files used by DotNetHelp can be stored on a server (as in webhelp) but the UI is actually available on the client?

If yes! How is this actually done? The interface does not seem to be able to open a website? or Is there some other trick?

Is the performance (experienced by the User) better? Does this reduce the number of files needed to be downloaded from the server to read a page?

Regards, Bruce