A chain of type forwarders is followed by assembly name, and every name resolves relative
to the assembly being decompiled - so a chain that leaves for another framework can be
pulled straight back into the directory it started in. A .NET Standard 2.0 assembly
sitting among .NET Framework 4.6.1 facades lost System.Linq.Enumerable that way: the
chain went netstandard -> System.Core (from the shared framework) -> System.Linq (back to
the input directory) -> netstandard, arriving at an assembly it had already passed
through. Nothing in the closure defines the type, so it stayed unknown and every LINQ
call decompiled as a static call with a delegate cast.
Once the closure is loaded, chains that return to an assembly they already visited are
walked a second time, resolving each hop next to the assembly that forwards it. The
assembly ending the repaired chain is loaded only once it is confirmed to declare the
type; it then wins the deduplication against the assembly of the same name it displaces,
which version order says nothing about. An assembly that neither forwards nor declares
the type ends the walk with nothing loaded, so a failed repair cannot displace anything.
Only chains that are already broken are walked twice. Preferring the forwarder's own
directory as a resolution policy was tried first and rejected: measured against a corpus,
it moved a .NET 8 facade's System.Runtime reference out of a net4x compilation, splitting
type identities so that overrides printed as virtual. The two cases cannot be told apart
where references are resolved, because that layer sees assembly names, not the type whose
chain is or is not terminating.
AssemblyReference now knows the module that declares it, which is what lets a hop be
resolved next to its forwarder, and its metadata reader is that module's.
A chain that cannot be repaired is reported in the reference load log the UI already
shows, once per reference: a facade forwards hundreds of types and they all fail together.
Assisted-by: Claude:claude-opus-5:Claude Code
ScopedRefAttribute only records explicit syntax. Effective lifetime also
depends on UnscopedRefAttribute, params collections, out parameters, and
the defining module's RefSafetyRules version. Model those distinctions in
the type system without changing decompiler output.
Assisted-by: Copilot:gpt-5.6-sol:GitHub Copilot CLI
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 86d2918e-5a24-48b4-9a86-41d331ec3720
Seems like a typo - the setter method was assigned to the Getter property
The test GuessAccessors needed adjustments in the generated code.
ILSpy is more eager to merge property assignments
We now avoid the old `IModuleReference` interface which required allocating for every type being resolved.
Instead `MetadataModule.ResolveModule` now combines decoding+resolving assembly references into a single step.
This allows the type system to maintain a cache indexed by row number.
This also changes the behavior of resolving references within a compilation: We now prefer an exact match (name + version + publickeytoken) first; and fall back to a name-only match only if no exact match exists.
This somewhat improves the decompilation of assemblies created by using ilmerge to combine assemblies with different target frameworks.
If this attribute is in use, private/internal members lack nullability annotations.
Previously in such cases, we ended up inheriting the nullability from the `[NullableContext]`, which could cause us to display a misleading nullability for primary methods.
In debug builds, it could also trigger an assertion when trying to apply the "nullable reference type" marking to to value types.
Of note is that properties and events are a special case: they do not explicitly store Accessibility in metadata. For properties computing the accessibility requires decoding the signature (to find overridden base properties). So these two only check the declaring type's accessibility instead; private properties may still carry nullability despite `[NullablePublicOnly]`. However, the property accessors won't store nullability, so we need to read the `returnTypeAttributes` from the property itself.
Also, assume that unknown inputs to ldfld are temporaries, not unmanaged pointers.
This avoids emitting weird pointer casts when accessing fields on unresolved value types.
While support for multi-module assemblies isn't fully working yet; it is clear at this point that we want
to treat each module in a multi-module assembly separately for the purposes of the type system.
This is a work-in-progress; ILSpy is not functional with this commit.
The old code path still exists but is broken because some classes were modified for the new system.
The new system is still highly incomplete (types only have fields, but no methods).
Siegfried Pammer
Sebastien Lebreton
Peter Crabtree
Maximilian Schmöcker
Daniel Grunwald
Standa Lukeš
James May
Matt Rouse
dotnet format