How to inherit from types in a dependent assembly?

Topics: User Forum
Oct 9, 2008 at 6:53 PM
I am documenting assemblies in different help files, and a type in assembly B inherits from a type in dependent assembly A.  Assembly A exists as a dependent assembly in assembly B's .shfb file.  I added assembly A to the Additional Reference Links plug-in, which allows links to that assembly to be generated properly.  However, inherited members from assembly A do not show up on the members pages for assembly B.  I tried adding assembly A as an assembly to document in assembly B's .shfb file, which resulted in the proper documentation of the inherited members, but if I filter out assembly A's namespace via the namespaces dialog or the API Filter, the inherited members do not show up once again.  Since I do not want assembly A to be documented in the help file for assembly B, I'm stuck.

Is there a way to get inherited members from another assembly to show up that I haven't thought of?  If not, can the Additional Reference Links plug-in be modified to do this?  Thanks for any help.
Oct 9, 2008 at 7:26 PM

As far as I know, it should work as you currently have it.  Can you send me an example that shows the problem with details as to what I'm looking for.  My e-mail address is in the About box and in the footer of the pages in the help file.



Oct 22, 2008 at 1:10 PM
I figured out that if I check the namespace for assembly A in the Namespaces dialog, but don't add it to the Assemblies to Document list, then the inherited members show up for assembly B, but the namespace for assembly A does not show up in the help file (which works as I want it to).  The only exception to that is that static members of the type in assembly A still do not show up as members in the inherited class in assembly B.  I will investigate a bit more to see if I can figure out why the static members aren't showing up.
Oct 22, 2008 at 3:08 PM
Static members belong to the class in which they are declared.  They are never inherited so will not show up in derived classes since you can't call them via the derived class, only via the class in which they are declared.

Oct 22, 2008 at 3:55 PM
I looked a little more closely at the classes I am documenting, and the one defining the static members is an abstract class.  So in this case the static members are inherited by the derived class.  This appears to be an issue within the same assembly as well though, so it might be an issue with Sandcastle.
Oct 22, 2008 at 6:36 PM

Abstract or not, static members still only show up in the class in which they are declared and are not truly inherited.  Even though you can call the static member using the derived class name in C#, the compiler's going to make it a call going through the base class which is where the member resides.  Compile the following example with or without the abstract method and look at it with Reflector and you'll see what I mean.  The call to DerivedTest.DoesNotInherit() gets compiled to a call to BaseTest.DoesNotInherit().  As such, you'll never see static methods from base classes listed in derived classes.

using System;

namespace StaticTest
    public class BaseTest
//        public abstract void ImplementThis();

        public static void DoesNotInherit()

    public class DerivedTest : BaseTest
//        public override void ImplementThis()
        public void ImplementThis()



Jan 15, 2009 at 12:34 PM

I am having problems inheriting from previously compiled 'base' objects.
I have followed the sugestions above, the inheritance links appear in the CHM file but when I click on them I get

Sorry, no topics were found for the selected link.

Keywords = ""
IndexMoniker =
Source URL =

It must be something I'm doing wrong but I cant figure it out.
Any help appreciated.

Jan 15, 2009 at 3:21 PM
Index links only work in Help 2 files.  For CHM files, select Local for ProjectLinkType and MSDN for SdkLinkType.

Jan 16, 2009 at 7:47 AM
I reset the project to as abpve but although I can see the references to the inherited objects (actually interfaces) , they are not "clickable".
Is this correct or should they be "clickable" ?
Is that what you mean by "Index links only work ... " ?
Jan 16, 2009 at 3:34 PM
If the base classes are in the .NET Framework, you should be seeing clickable links that go to the online MSDN content.  That's what setting SdkLinkType to MSDN does.  If the base classes are not in the .NET Framework and are in an assembly that you are not documenting (i.e. a reference assembly), then they won't be clickable as they aren't being documented and don't appear in the help file.  If you need the base classes documented, you'll need to include the reference assembly as a documentation source instead.  That's how the Local setting for ProjectLinkType works (local is within the current help file only).

The Index setting is for Help 2 (HxS) files only.  For either link type property, the Index value tells it to generate links that are looked up in the Help 2 collection indexes and it'll find matches across any help file in the collection.  That's not an option for Help 1 (CHM) files since they're standalone and don't integrate into any collection.

Jan 18, 2009 at 12:36 AM
I needed a similar result. As Eric says, if you do not target HTML Help 2 you have to generate the documentation for the assemblies together in one project. However, my project was quite big, the compilation took quite a time, and I did not want to maintain more sets of SHFB projects for testing and production. What was my goal:

* to build and update the documentation for every assembly separately (independently)
* to have a common table of contents and index
* to have links among types and members in those assemblies
* to be able to build the final set of assemblies flexibely - add or remove one or two without rebuild
* support CHM and Web (not HTML Help 2, at least yet)

I ended up writing an SHFB plugin storing some important files during a project compilation (reflection.xml, index, contents) for future projects referring to this one. Modifying links in the generated HTML files too. The documentation looks like:

AssemblyA.chm - documentation for the AssemblyA
AssemblyB.chm - documentation for the AssemblyB (with cross-CHM links to AssemblyA)
Compilation.chm - common documentation and merged-in CHMs of the assemblies

http://xxx/AssemblyA/... - documentation for the AssemblyA
http://xxx/AssemblyB/... - documentation for the AssemblyB (with relative links to AssemblyA)
http://xxx/Compilation/... - common documentation and relative links to the assemblies

The easiest way is to build everything in one project or target just HTML Help 2. If you still want to generate the documentation independently, you can consider my solution.

Sep 17, 2009 at 6:52 PM
lhannan wrote:
I figured out that if I check the namespace for assembly A in the Namespaces dialog, but don't add it to the Assemblies to Document list, then the inherited members show up for assembly B, but the namespace for assembly A does not show up in the help file (which works as I want it to).

Thanks to this information, and also now knowing that v1.8 has Documentation Sources under the Project Explorer replacing what was Assemblies to Document in v1.7, I got the perfect result.  I did include A.xml as a Documentation Source.