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, and some special attributes used by AjaxDoc and Script# 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 XSL 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 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.

Other Resources