Issues Preventing DotNet Help Rollout

[Robotman]

Hello

I just got this message back from my manager and developers in regards to rolling out Dot Net Help in our applications.

The following is a list of items preventing us from using Dot Net Help in the short-term (even though all of us are really keen to include it in our apps). If anybody has any solutions/suggestions to these then I'd love to hear from you. I will submit these items as feature requests.

1. msm install creates a desktop icon
2. file type registration only occurs after manually running the viewer
3. the viewer stores all settings in the registry under 'current user' and not local machine
4. the viewer insists on prompting for the language
5. the viewer insists on prompting for the install of MS-SQL Compact
6. the multiple files structure of the help means that ANY file change by the documenter in generating the help will have to be manually updated in the InstallShield project (negating the use of Automated BuildStudio).

I won't get worked up about it but I do hope that Madcap looks into these issues and addresses them. If others consider these to be issues, then please submit an enhancement request at the usual location.

Thanks,

[RamonS]

In regards to point 6, can the installation engineer not just include all contents of a specific folder? I know that we did this with INNO Setup using WebHelp locally. Worked fine and the install script had not to be changed ever for any help related issues.

[Robotman]

In regards to point 6, can the installation engineer not just include all contents of a specific folder? I know that we did this with INNO Setup using WebHelp locally. Worked fine and the install script had not to be changed ever for any help related issues.

This was my first thought too, Ramon. We're a small (<15) company and we don't have a permanent dev working with our installer software (installshield) but we're definitely looking into it. Cheers.

On the other points, got an email back from tech support (who talked with the devs) and basically everything listed is how it's done and it's not currently possible to change this. They're logged them as feature requests so I'm not sure if we'll see any changes until v5 (which is a shame as we're eager to move to dot net help). We can't have 500 client machines having the help viewer installed and requiring them all to run the viewer software first before they can open the *mchelp files (plus the issue of the logo on the desktop and having to select their language).

[Robotman]

Whilst I don't have time to investigate the above items yet (software rollout in the next fortnight), has anybody looked into any of the issues listed in the original post?

[RamonS]

Not really. DotNetHelp is hampered by being a proprietary format that needs a proprietary reader. I vaguely recall that someone managed to get the install included in their own app install and run it silently, but it still puts an icon on the desktop. There are still plenty of things that are off that make DotNetHelp not to be a good choice for most apps. It is weird, MadCap puts effort into a new help platform and then packages it up and makes it behave in such a way that it becomes unusable.