Traversing Assemblies & Feature Trees

01Why traversal comes before everything else

Automation that modifies models is where the visible value is. Automation that only looks is where the safe value is, and it is almost always the better first project.

02Configuration first

You cannot ask an assembly directly for its components. You ask a configuration, because what an assembly contains depends on which configuration is active — components may be suppressed in one and resolved in another.

IConfiguration swConf = (IConfiguration)swModel.GetActiveConfiguration();
IComponent2   swRoot  = (IComponent2)swConf.GetRootComponent();

if (swRoot == null) { /* not an assembly, or nothing resolved */ return; }

Walk(swRoot, 0);

The root component represents the assembly itself. It is not something the user sees as a component, but it is the node whose children are the top-level components, and every traversal starts there.

03The recursion pattern

One routine, calling itself. The depth argument is not required by the API — it exists so that the output can be indented, which turns a flat list into something a human recognises.

void Walk(IComponent2 component, int depth)
{
    Record(component, depth);          // your own reporting

    object[] children = (object[])component.GetChildren();
    if (children == null) return;      // a leaf: a part, or nothing resolved

    foreach (object child in children)
        Walk((IComponent2)child, depth + 1);
}

Three details make the difference between a traversal that works and one that works on real assemblies:

• Test the children for null. A part has no children, and the call returns nothing rather than an empty array. Iterating without the test fails on the first part reached.
• The same part appears many times. Traversal visits instances, not unique documents. Counting parts means collecting distinct paths; counting instances means counting visits. Decide which question you are answering.
• Suppressed branches stop. A suppressed component reports no children, so an audit that ignores suppression silently under-reports. Record the state alongside the name.

04Walking features

The feature tree is a chain rather than a nested structure: each feature knows the next one. Sub-features hang off individual features as a second chain.

IFeature feat = (IFeature)component.FirstFeature();

while (feat != null)
{
    Record(feat.Name, feat.GetTypeName2());

    IFeature sub = (IFeature)feat.GetFirstSubFeature();
    while (sub != null)
    {
        Record("   " + sub.Name, sub.GetTypeName2());
        sub = (IFeature)sub.GetNextSubFeature();
    }

    feat = (IFeature)feat.GetNextFeature();
}

The same chain is walked from a document rather than a component when you are working inside a single part — the document exposes its own first feature, and the loop is otherwise identical.

05Filtering what you report

A raw feature dump is unreadable. Every useful traversal filters, and the type name is how you filter.

06Suppression states

Suppression is the most common thing an audit needs to read and the most common thing an engineer wants to change in bulk. Components and features handle it differently.

07Reporting and performance

Traversal produces data. What you do with it determines whether the tool gets used twice.

Large assemblies

Traversal is fast until it is not. Four measures keep it usable:

• Read once, use many times. Collect what you need into your own structures during a single pass, rather than making repeated calls across the interop boundary for the same information.
• Do not resolve what you do not need. Resolving lightweight components to read a name is expensive. Resolve only where the data you require demands it.
• Report progress. A traversal of a large assembly takes long enough that silence will be interpreted as a hang.
• Guard the depth. A depth limit costs nothing and protects against pathological structures that would otherwise exhaust the stack.

08Quick reference