[GH-ISSUE #1812] [Bug] inspect-managed-members reports .NET facade assemblies as complete with zero types because exported (forwarded) types are never parsed #610

Closed
opened 2026-10-15 18:26:37 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @JasonBuildAI on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1812

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

inspect-managed-members (and the MCP inspect_managed_members tool) reports .NET facade assemblies as a complete inspection with zero members. The ExportedType metadata table, which holds type forwarders, is never parsed, so every type a facade provides is invisible. inspect-managed-artifact already counts those rows on the same file.

Reproduction

  1. Use any .NET facade / type-forwarding assembly. Two public examples:
    • System.Runtime.dll from the .NET 7 runtime (C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.20\System.Runtime.dll)
    • System.Web.Routing.dll from the in-box .NET Framework 4.8 (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.Routing.dll)
  2. Run rea inspect-managed-members <path> --format json and rea inspect-managed-artifact <path> --format json.
  3. Observe that members returns only <Module> with coverage.state: "complete", while artifact reports a non-empty ExportedType row count (861 for System.Runtime.dll, 15 for System.Web.Routing.dll).

Expected behavior

The member inventory should include the assembly's exported/forwarded types with their implementation scope (AssemblyRef, File, or a nested exported type), or coverage must not claim completeness while an entire metadata table is omitted. System.Runtime.dll provides roughly 861 types through forwarding; an empty types array with "complete" coverage reads as "this assembly declares nothing".

Impact and scope

  • Anyone inspecting a .NET Core/5+ facade (System.Runtime.dll is referenced by every .NET app) or an in-box framework facade sees an empty inventory that claims complete coverage.
  • compare-managed-members compares only declared TypeDef/Field/MethodDef rows, so two versions of a facade report zero differences even when the forwarded set changed.
  • Observed-only data is not affected: the canonical metadata row counts already prove the table is present; nothing here involves executing or loading target code.

REA version

rea-agents 6.4.0 (source revision 0153b4d9)

Runtime and platform

Node 22.22.2; Windows 11 (win32 x64); no provider involved

Target and artifact context

PE/CLI x86-64 managed assemblies; Microsoft-shipped facades (type forwarders only); no native runtime involved.

Interface

CLI

Earliest failure stage

Artifact or evidence registration

Relevant output or evidence

$ rea inspect-managed-members "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.20\System.Runtime.dll" --format json
types: 1 (<Module>)
methods: 0
fields: 0
coverage: { "state": "complete", "issues": [] }

$ rea inspect-managed-artifact "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.20\System.Runtime.dll" --format json
table_row_counts: { "TypeDef": 1, "AssemblyRef": 2, "ExportedType": 861, ... }

$ rea inspect-managed-members "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.Routing.dll" --format json
types: 1 (<Module>)
methods: 0
coverage: { "state": "complete", "issues": [] }

$ rea inspect-managed-artifact "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.Routing.dll" --format json
table_row_counts: { "TypeDef": 1, "ExportedType": 15, ... }

Typed outcome or recovery expected

inspect_managed_members should surface exported types (e.g. an exported_types array with namespace/name, flags, the forwarded type's TypeDefId, and its implementation scope). Until then, completeness should at least name the omitted table.

Analysis or suspected cause

Marked hypothesis: src/dotnet/ManagedMemberInspector.ts parses TypeDef, Field, MethodDef, MemberRef and bodies, but no code reads table 39 (ExportedType). ManagedMetadataLayout and ManagedMetadataRowSizes already compute its row layout (Implementation coded index over File/AssemblyRef/ExportedType), and inspect-managed-artifact reports its row count, so only the projection is missing.

Additional context

Type forwarders are the normal shape of .NET Core facades; the same table also carries multi-module exported types. A regression test can build a facade fixture where a forwarded type points at an AssemblyRef.

Originally created by @JasonBuildAI on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1812 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `inspect-managed-members` (and the MCP `inspect_managed_members` tool) reports `.NET` facade assemblies as a complete inspection with zero members. The `ExportedType` metadata table, which holds type forwarders, is never parsed, so every type a facade provides is invisible. `inspect-managed-artifact` already counts those rows on the same file. ### Reproduction 1. Use any .NET facade / type-forwarding assembly. Two public examples: - `System.Runtime.dll` from the .NET 7 runtime (`C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.20\System.Runtime.dll`) - `System.Web.Routing.dll` from the in-box .NET Framework 4.8 (`C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.Routing.dll`) 2. Run `rea inspect-managed-members <path> --format json` and `rea inspect-managed-artifact <path> --format json`. 3. Observe that members returns only `<Module>` with `coverage.state: "complete"`, while artifact reports a non-empty `ExportedType` row count (861 for `System.Runtime.dll`, 15 for `System.Web.Routing.dll`). ### Expected behavior The member inventory should include the assembly's exported/forwarded types with their implementation scope (AssemblyRef, File, or a nested exported type), or `coverage` must not claim completeness while an entire metadata table is omitted. `System.Runtime.dll` provides roughly 861 types through forwarding; an empty `types` array with `"complete"` coverage reads as "this assembly declares nothing". ### Impact and scope - Anyone inspecting a .NET Core/5+ facade (`System.Runtime.dll` is referenced by every .NET app) or an in-box framework facade sees an empty inventory that claims complete coverage. - `compare-managed-members` compares only declared `TypeDef`/`Field`/`MethodDef` rows, so two versions of a facade report zero differences even when the forwarded set changed. - Observed-only data is not affected: the canonical metadata row counts already prove the table is present; nothing here involves executing or loading target code. ### REA version rea-agents 6.4.0 (source revision 0153b4d9) ### Runtime and platform Node 22.22.2; Windows 11 (win32 x64); no provider involved ### Target and artifact context PE/CLI x86-64 managed assemblies; Microsoft-shipped facades (type forwarders only); no native runtime involved. ### Interface CLI ### Earliest failure stage Artifact or evidence registration ### Relevant output or evidence ``` $ rea inspect-managed-members "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.20\System.Runtime.dll" --format json types: 1 (<Module>) methods: 0 fields: 0 coverage: { "state": "complete", "issues": [] } $ rea inspect-managed-artifact "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\7.0.20\System.Runtime.dll" --format json table_row_counts: { "TypeDef": 1, "AssemblyRef": 2, "ExportedType": 861, ... } $ rea inspect-managed-members "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.Routing.dll" --format json types: 1 (<Module>) methods: 0 coverage: { "state": "complete", "issues": [] } $ rea inspect-managed-artifact "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\System.Web.Routing.dll" --format json table_row_counts: { "TypeDef": 1, "ExportedType": 15, ... } ``` ### Typed outcome or recovery expected `inspect_managed_members` should surface exported types (e.g. an `exported_types` array with namespace/name, flags, the forwarded type's TypeDefId, and its implementation scope). Until then, completeness should at least name the omitted table. ### Analysis or suspected cause Marked hypothesis: `src/dotnet/ManagedMemberInspector.ts` parses `TypeDef`, `Field`, `MethodDef`, `MemberRef` and bodies, but no code reads table 39 (`ExportedType`). `ManagedMetadataLayout` and `ManagedMetadataRowSizes` already compute its row layout (`Implementation` coded index over `File`/`AssemblyRef`/`ExportedType`), and `inspect-managed-artifact` reports its row count, so only the projection is missing. ### Additional context Type forwarders are the normal shape of .NET Core facades; the same table also carries multi-module exported types. A regression test can build a facade fixture where a forwarded type points at an `AssemblyRef`.
bsakaguchi 2026-10-15 18:26:37 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#610
No description provided.