Introduction

Yes, but not usually as an automatic "merge these two generated API topics into one" feature. In Sandcastle-style documentation workflows, the practical answer is to create a higher-level conceptual topic or restructure the table of contents so both generated topics appear under one main entry.

Understand the difference between API topics and conceptual topics

Sandcastle-generated API pages are usually derived from reflection data and XML comments. They represent specific namespaces, types, or members. Conceptual topics, by contrast, are authored documentation pages that you control directly.

That distinction matters because generated API topics are not normally meant to be hand-edited after generation. If you want one "main page" that presents two generated topics together, the cleanest solution is often to create a conceptual page that links to or summarizes both.

A practical TOC approach

A common workflow is to create one higher-level conceptual page and place the two generated topics beneath it in the table of contents.

1<Topics>
2  <Topic id="MainOverview" visible="true">
3    <Title>Main Overview</Title>
4    <Topic id="GeneratedTopicA" visible="true" />
5    <Topic id="GeneratedTopicB" visible="true" />
6  </Topic>
7</Topics>

This does not literally fuse the two generated HTML pages into one file, but it gives readers a single landing page and a unified navigation structure, which is usually the real goal.

When you really want one physical page

If you truly need one physical page, then you are no longer just changing navigation. You are changing the build output model. That usually means custom conceptual content, custom transforms, or post-processing the generated output.

That is possible, but it is more brittle. Generated documentation systems are much easier to maintain when you keep generated API content separate from authored content and use conceptual pages as the glue.

Why the conceptual-page solution is better

A conceptual main page lets you:

• explain how the two generated topics relate
• provide the right order and context for readers
• avoid editing generated output by hand
• keep rebuilds repeatable

That is usually a better documentation design than physically stitching two generated pages together, especially if the API content changes frequently.

Think in terms of documentation architecture

The real question is often not "can I merge the files?" but "what reading experience do I want?" If readers need one entry point, create that entry point as authored content. If they need one flat page for printing or export, then a custom transform or post-build merge may be justified.

In other words, information architecture should drive the solution, not just the desire to reduce page count.

Common Pitfalls

• Editing generated Sandcastle output by hand and then losing the changes on the next rebuild.
• Treating table-of-contents grouping and physical page merging as if they were the same thing.
• Forcing two API topics into one page when a conceptual overview page would be clearer.
• Building a fragile post-processing pipeline for a problem that navigation structure could solve more simply.
• Ignoring how rebuildability and maintainability affect documentation quality over time.

Summary

• Sandcastle does not usually solve this as an automatic "merge two generated pages" feature.
• The cleanest solution is often to create a conceptual main page and group both generated topics under it.
• Physical page merging is possible only with more custom build or post-processing work.
• Conceptual pages are the best place to explain relationships between generated API topics.
• Prefer maintainable documentation architecture over manual editing of generated output.