Example of how to exclude class members?

Question

It is not clear how the examples in mrefbuilder.config apply to class members. Help is appreciated.

Thanks

Henrik

Answer 1

Hi Henrik,

I've been playing around with the namespace ripping feature and here's what I've found.  The config file should look like this:

<configuration>
  <dduetools>
    <platform version="2.0" path="%SystemRoot%\Microsoft.NET\Framework\v2.0.50727\" />
    <apiFilters>
        <!-- API filters go here -->
    </apiFilters>
    <attributeFilters>
        <!-- Attribute filters go here -->
    </attributeFilters>
  </dduetools>
</configuration>

Attribute filters are the easiest.  If you want to include all attribute information on the types and their members, just omit the section entirely.  If you want to limit it to a specific set of attributes, you'll have one entry for each attribute that you'd like to see and a final entry to exclude all others.  For the inclusion filters, just specify the namespace and type in the filter's attributes and set the expose attribute to true.  The final entry should just have an expose attribute set to false:

    <attributeFilters>
      <!-- Include these attributes -->
      <filter namespace="System" type="FlagsAttribute" expose="true" />
      <filter namespace="MyNamespace" type="MyCustomAttribute" expose="true" />
      <!-- Exclude all others -->
      <filter expose="false" />
    </attributeFilters>

API filters are similar.  To exclude an entire namespace, just specify the namespace attribute and set the expose attribute to false.

    <apiFilters>
      <!-- Filter out an entire namespace -->
      <filter namespace="TestDoc.Hidden" expose="false" />
    </apiFilters>

To filter out a specific type, add a type attribute.

    <apiFilters>
      <!-- Filter out a single type -->
      <filter namespace="TestDoc" type="HiddenClass" expose="false" />
    </apiFilters>

To filter out a specific member, you add a member attribute.  However, this currently only works in theory as when you do add the member attribute, the entire type disappears again.  I believe this is a bug in MRefBuilder.  I've submitted it so I'm waiting to hear back on that.  In addition, it's not clear exactly what the format of the member attribute should be when the member has parameters so I've requested information on that too.

Eric

 

Answer 2

I took a look at MRefBuilder with Reflector and figured out how to exclude individual members.   Set it up like this:

<filter namespace="TestDoc" type="HiddenClass" member="*" expose="true" />
<filter namespace="TestDoc" type="HiddenClass" member="HiddenMember" expose="false" />

When testing to include types, the first filter matches the type name and causes it to be included (the type match ignores the member name).   When testing to include member names, the first filter doesn't match any member name and the search continues.  A blank/empty member attribute matches all members, and would cause them to be included.    The "*" doesn't have any real significance; it's just a string that won't match any member names.  If a memeber doesn't match any rules, it will be included by default.

The member comparison is only by name.  There's no way to exclude a specific overload.

/Frank

Answer 3

Thanks Frank. We will fix this issue for our next drop.

 

Anand..

Answer 4

On Overloads you can suppress all overloads by not running the AddOverloads doc model transform. You can do this by removing the highlighted portion from this step.

XslTransform /xsl:..\..\ProductionTransforms\AddOverloads.xsl reflection.org /xsl:..\..\ProductionTransforms\AddGuidFilenames.xsl /out:reflection.xml

The current exclude (ripping) logic doesn’t allow a specific overload to be ripped – either all overloads of a particular method are ripped or none are. If all are ripped, there will be no overloads page because there are no method pages. In the second case, there would continue to be an overloads page when there were multiple overloads of the method.

Suppose we were to make it possible to rip a specific overload of a method, it still wouldn’t make any sense to rip the overloads page. (Where would a link to a non-specific method go, for example.) The overloads pages are elements of the document model, not the exposed APIs.

 

Anand..