ILSpy

9745 Commits

54 Branches

94 Tags

91 MiB

Tree: fa464968e1

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	af941339c0	Fix #2054 : repair a chain of type forwarders that cycles 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	2 weeks ago
Peter Crabtree	e1e16b64f5	dev: Strip BOM mark from text files	1 year ago
Siegfried Pammer	5734da4294	Fix #2314 : ILSpy incorrectly resolves a runtime dependency when dll is present in both WindowsDesktop.App and NETCore.App	6 years ago

Author

SHA1

Message

Date

Siegfried Pammer

af941339c0

Fix #2054 : repair a chain of type forwarders that cycles

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

2 weeks ago

Peter Crabtree

e1e16b64f5

dev: Strip BOM mark from text files

1 year ago

Siegfried Pammer

5734da4294

Fix #2314 : ILSpy incorrectly resolves a runtime dependency when dll is present in both WindowsDesktop.App and NETCore.App

6 years ago

3 Commits (fa464968e1bb7ab84939d31d4dcd73eff3f44588)