ILSpy

9696 Commits

54 Branches

94 Tags

91 MiB

Tree: 2b21f508e0

Commit Graph

Author	SHA1	Message	Date
Christoph Wille	2b21f508e0	Fix #2362 : resolve Xamarin compressed references in ilspycmd Since the input file goes through ILSpyX's FileLoaderRegistry, an XALZ module passed directly to ilspycmd already decompresses on the fly. The crash in the issue is in reference resolution: a Xamarin app folder holds every assembly compressed, and UniversalAssemblyResolver opened the referenced sibling as a plain PE image. In the CLI that failure was swallowed, so the reference resolved to null and the output degraded (enum members printed as casts of raw values, and so on). The UI does not have this problem because its resolver only asks the universal resolver for the file name and then loads it through the loaders. Rather than re-implementing the resolver in the CLI, the universal resolver gains one overridable step - turning a found file into a module - and the CLI overrides it to run the same loader loop the input file uses, falling back to the plain PE path for anything no loader claims. Assisted-by: Claude:claude-fable-5-1:Claude Code	2 weeks ago
Siegfried Pammer	71ac2b9ca9	Fix #3154 : accept single-file bundles as ilspycmd input Every mode loaded the input file with its own `new PEFile(fileName)` call, so a bundle - which the UI opens fine, because LoadedAssembly goes through the file loader registry - failed identically in all of them. The five call sites now share one load helper that runs the same registry, which also makes archives work and keeps one detection point for both front ends. Which assembly inside a bundle is meant is not something to guess, so a package without --bundle-entry lists its managed entries and exits non-zero. The entry point is only annotated in that listing: the manifest has no marker for it, so it is derived the way the host does it, from the runtime-config entry's name, and stays unannotated where that does not resolve. Assisted-by: Claude:claude-opus-5:Claude Code	2 weeks ago

Author

SHA1

Message

Date

Christoph Wille

2b21f508e0

Fix #2362 : resolve Xamarin compressed references in ilspycmd

Since the input file goes through ILSpyX's FileLoaderRegistry, an XALZ
module passed directly to ilspycmd already decompresses on the fly. The
crash in the issue is in reference resolution: a Xamarin app folder
holds every assembly compressed, and UniversalAssemblyResolver opened
the referenced sibling as a plain PE image. In the CLI that failure was
swallowed, so the reference resolved to null and the output degraded
(enum members printed as casts of raw values, and so on). The UI does
not have this problem because its resolver only asks the universal
resolver for the file name and then loads it through the loaders.

Rather than re-implementing the resolver in the CLI, the universal
resolver gains one overridable step - turning a found file into a
module - and the CLI overrides it to run the same loader loop the input
file uses, falling back to the plain PE path for anything no loader
claims.

Assisted-by: Claude:claude-fable-5-1:Claude Code

2 weeks ago

Siegfried Pammer

71ac2b9ca9

Fix #3154 : accept single-file bundles as ilspycmd input

Every mode loaded the input file with its own `new PEFile(fileName)` call, so a
bundle - which the UI opens fine, because LoadedAssembly goes through the file
loader registry - failed identically in all of them. The five call sites now
share one load helper that runs the same registry, which also makes archives
work and keeps one detection point for both front ends.

Which assembly inside a bundle is meant is not something to guess, so a package
without --bundle-entry lists its managed entries and exits non-zero. The entry
point is only annotated in that listing: the manifest has no marker for it, so
it is derived the way the host does it, from the runtime-config entry's name,
and stays unannotated where that does not resolve.

Assisted-by: Claude:claude-opus-5:Claude Code

2 weeks ago

2 Commits (2b21f508e0bdd3ea655304783fa5d103fcd3f5f8)