Output Formats

A single Markdown help template can generate up to six output formats. The formats to build are selected to build per project; the same templates and authored content feed all of them.

Format	What it produces	How it is used
CHM	One .chm file	Shipped with the driver
Microsoft Help Viewer	An .mshc package	Installed into the Visual Studio Help Viewer
Markdown	.md files and a SUMMARY.md	Read in a repository, built into a book, or transformed
Semantic HTML	Plain HTML, no chrome	Folded into an existing site or toolchain
MadCap Flare HTML	Content shaped for Flare	Imported into a MadCap Flare project
Starlight website	A built, branded site	Published to any web host

Only the Starlight website needs anything installed to build it. The rest are produced by Nimbus alone.

The formats

CHM (Microsoft Help 1)

The classic compiled HTML Help (.chm): a single file holding the whole help set, with contents, index, and search. Ship it alongside the driver — most driver installers place it next to the driver’s files and add a Start menu shortcut — and it opens in the Windows help viewer with no prerequisites.

Microsoft Help Viewer (MSHC)

Packaged help (.mshc) for the Visual Studio Help Viewer, so a driver’s reference sits beside the .NET and Visual Studio documentation the user already has installed. Nimbus can register the content on build for local testing, and the package is what an installer deploys on the user’s machine. It can be signed; see the signing and registration options below.

Markdown

Clean GitHub-Flavored Markdown files, plus a SUMMARY.md table of contents. Three uses are common:

• Committed to a repository and read on GitHub or GitLab. Both render Markdown as the files are browsed, and the links between pages resolve.
• Built into a book by a tool that reads SUMMARY.md. For mdBook the configuration is generated as well: run mdbook build in the mdbook folder to produce a navigable site with search, or mdbook serve to read it locally. HonKit reads the same table of contents.
• Transformed by a pipeline — the files carry no chrome and no help-system metadata, so they are straightforward to process.

A topic that appears in several places in the table of contents is written once for each place, named under the page it sits beneath. That is what allows the driver hierarchy to show a member under every interface that provides it, the way IntelliSense does, while still giving every entry a file of its own.

Note

This format is a set of files, not a web site. Publishing these files to GitHub Pages does not produce a documentation site: Pages runs Jekyll, which needs its own layouts and configuration and does not read SUMMARY.md. MkDocs and Docusaurus likewise need navigation configured in their own format.

For a site to publish, use the Starlight website format below, which carries exactly the configuration this format lacks.

Semantic HTML

Chrome-free HTML with stable, meaningful class names and no help-system metadata — intended for integrators who want to fold the content into their own website or toolchain.

MadCap Flare HTML

Content prepared for import into a MadCap Flare project, where a documentation team applies its own chrome and styling.

Two tables of contents are written, and which one a Flare target should use depends on what it builds:

File	Use it for
<driver>.fltoc	The online help
<driver>-pdf.fltoc	The PDF

They differ in one way. The driver hierarchy shows a member under every interface that provides it, the way IntelliSense does, so a member inherited by three interfaces appears three times, and once more in the interface list. Online those are simply several ways to reach one page, and a reader who arrives by one of them never needs to know about the others.

A PDF prints every page its table of contents names. Given the same list, it prints that member four times, and the more capabilities a driver has the more the document repeats itself. So <driver>-pdf.fltoc lists each topic once — the first place it appears — while keeping every topic the full one reaches.

Note

Both files point at the same pages. Choosing one table of contents rather than the other changes what a target includes, not what it renders, so a Flare project can build both from a single import.

Starlight website (Astro Starlight)

A complete, ready-to-deploy documentation site built with Astro Starlight: full-text search, responsive layout, dark/light mode, and syntax highlighting, with custom branding. Upload the built site to any static web host. See The Starlight Web Site for the full workflow — generating, previewing, branding, and deploying.

Note

Building the Starlight website requires Node.js on the build machine — see Prerequisite: Node.js for the required version. All the other formats are produced entirely by Nimbus with no additional tooling. Use npm run dev for a local preview during authoring and npm run build to produce the final static site.

Choosing which formats to build

The formats may be selected in any of these places — they all set the same project settings:

• The General page of the help project’s properties.
• The New Help Project wizard, when the project is created.
• Tools → Options → Help, for the default choices applied to new projects.

Each format corresponds to a project property (BuildHelp1, BuildHelp3, BuildMarkdown, BuildSemanticHtml, BuildFlare, BuildStarlight), so the selection is stored with the project and honored by command-line builds. The Microsoft Help Viewer format additionally has signing and registration options (signing certificate thumbprint, register on build).

See Building and Viewing the Help Content for building and previewing.

Format availability

All six formats are produced by the Markdown help template system. A driver whose help project uses the older HTML template system produces only the two classic formats — CHM and Microsoft Help Viewer; switching it to a Markdown template unlocks the rest.