The following properties are available in the Visibility category. These control what appears in the help file and can reduce the help content and get rid of unwanted items, especially when documenting internal and private members.
When set to false, the default, the help file builder will strip all attribute information from the documented items so that they do not appear in the syntax section of each class, property, method, etc. in the compiled help file. When set to true, the attribute information is left intact and will appear in the help file. Several attributes such as ExtensionAttribute, FixedBufferAttribute, FlagsAttribute, SerializableAttribute, ObsoleteAttribute are always included regardless of this property's setting as they provide important information about the types and members to which they are applied or are used by other components such as the syntax generators or presentation style transformations.
When set to false, the default, explicit interface implementations are removed from the help file. This includes explicit implementations in base classes so that they do not appear in the class members help pages. Set this property to true to include them in the help file.
When set to true, the default, all inherited members of the class are listed in the class members help page. When set to false, all inherited members including inherited .NET Framework class members are removed from the class members help pages. This can be useful when documenting internal or private members to help reduce clutter.
When set to true, the default, all inherited .NET Framework members of the class (any members starting with "System." or "Microsoft.") are listed in the class members help pages. When set to false, all inherited .NET Framework class members are removed from the class members help pages. This can be useful when documenting internal or private members to help reduce clutter. For this option to work, Document Inherited Members must also be set to true. When it is set to false, all framework members are removed.
When set to false, the default, all inherited .NET Framework members that have internal (Friend) visibility (any internal members starting with "System." or "Microsoft.") are removed from the class members help pages. This can be useful when documenting internal or private members to help reduce clutter. For this option to work, Document Inherited Framework Members and Document Internals must also be set to true. When this property is set to true, internal framework members are included.
When set to false, the default, all inherited .NET Framework members that have private visibility (any private members starting with "System." or "Microsoft.") are removed from the class members help pages. This can be useful when documenting internal or private members to help reduce clutter. For this option to work, Document Inherited Framework Members and Document Privates must also be set to true. When this property is set to true, private framework members are included.
When set to false, the default, the help file builder will not document any internal (Friend) members in the documentation assemblies. Because they share a similar visibility, protected internal members will be left in the help file when this is set to true even if the Document Protected property is set to false. Also note that this property works independently of the Document Privates property below.
When set to false, the default, the help file builder will not document any private fields in the documentation assemblies. Since most private fields back properties or represent items such as controls on forms, they usually do not have comments and can significantly clutter the resulting help file with unwanted entries. Leaving this option set to false can eliminate the problem. When set to true, the private fields are included in the help file. To work, the Document Privates property must also be set to true.
When set to false, the default, the help file builder will not document any private members in the documentation assemblies. Note that this property works independently of the Document Internals property above.
When set to true, the default, the help file builder will document all protected and protected internal members in the documentation assemblies. When false, the help file builder will remove them from the help file including those inherited from base .NET framework classes (those starting with "System." and "Microsoft."). Because they share a similar visibility, protected internal members will be left in the help file when the Document Internals property is set to true even if this property is set to false.
When set to false, the default, the help file builder will remove all protected members from sealed classes so that they do not appear in the help file. When true, the help file builder will document all protected members of sealed classes in the documentation assemblies. To work, the Document Protected property must also be set to true.
When set to false, the default, the help file builder will remove all "no-PIA" embedded interop types (those marked as compiler generated with a type identifier attribute). When true, such types are documented. Examples of these types are the Microsoft Office reference assemblies used in Office add-in projects.
When set to false, the default, the help file builder will remove all compiler generated types and members from the help file. This is usually the desired behavior as compiler generated types are typically internal constructs that are not wanted in the help file. However, in some cases, the compiler generated types may be wanted such as for compiler generated resource classes or data access classes. When true, such types and members are included but only if they are public. Any private, internal, and protected compiler generated types and members will still be removed.
When set to false, the default, the help file builder will exclude all types and members marked with an EditorBrowsableAttribute set to Never. If set to true, they are included. Types and members must be explicitly marked with the attribute to be excluded. Types derived from excluded types and overridden members that are not explicitly marked again will be included. This mimics the behavior of the Object Browser tool window in Visual Studio.
When set to false, the help file builder will exclude all types and members marked with a BrowsableAttribute set to False. If set to true, the default, they are included. Types and members must be explicitly marked with the attribute to be excluded. Types derived from excluded types and overridden members that are not explicitly marked again will be included. This mimics the behavior of the Object Browser tool window in Visual Studio.
When set to false, the default, the help file builder will exclude internal members from base types in other assemblies and private members from base types. If set to true, those members are included if the related internal and private member options are also enabled. This does not affect internal and private members inherited from base framework types. Those are included or excluded based on the related options described above.
When set to true, the default, the help file builder will alter protected internal members so that they are listed as protected only in the help file. When true, the help file builder will document all protected internal members of classes in the documentation assemblies without modification. If Document Protected is set to false, this option is ignored.
This property represents a collection of items that define an API filter for the MRefBuilder tool. The items in this filter define which elements of a namespace or type should be omitted from the generated reflection information file and thus the resulting help file. This is useful for excluding unwanted types and members, especially those generated by the compiler, and inherited base class members. Namespaces excluded in the Namespace Summaries property and items containing an <exclude /> tag in their XML comments are automatically added to the API filter at build time. If there is a conflict between these items and the API filter, the API filter will take precedence and a warning is written to the log file to note the conflict. See the API Filter Property topic for more details on how to use this property.