ILSpy

9783 Commits

54 Branches

94 Tags

91 MiB

Tree: 49ca126fb8

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	bb1d830ee6	Fix #2040 : escape BAML strings that XML cannot represent Obfuscators put arbitrary characters into BAML strings, and XML 1.0 has no representation for most control characters - a numeric character reference is invalid for them too. Writing such a document threw ArgumentException from XmlWriter, which loses the resource on project export and shows an exception instead of the page in the UI. The escapes are spelled the way the C# output spells them, so one convention covers both languages. Namespace URIs have to be escaped where the XNamespace is created rather than in the final pass: the URI is baked into every element name built from it, so patching only the xmlns declaration would desync the two. Characters XML can carry stay untouched, so ordinary documents decompile byte-identically. Every BAML stream of an assembly lives in one .resources container, and the recovery around resource writing sat outside the loop over its entries, so a single page that could not be written discarded every other page sharing the container with it. Assisted-by: Claude:claude-opus-5:Claude Code	2 weeks ago
Siegfried Pammer	a5bd230e14	Walk the whole decompiler pipeline in the Debug Steps pane The pane used to split the pipeline across two languages: the ILAst language stepped the IL transforms, the C# language stepped the AST transforms, and nothing showed the seam between them, so a step index meant a different thing depending on which language happened to be selected. Recording both halves into one Stepper makes an index replayable across the whole pipeline; a limit that lands in the IL phase has no C# to print, so the halted function is rendered as ILAst instead. Which function that is takes some care, because a member group's EndStep is the next member's first step: a halt standing on a member's opening step belongs to the member that just finished, a transform that throws where the limit was aimed has to hand over the ILAst it half-transformed (what the ILAst language showed as "ILAst after the crash"), and a step recorded on a helper function the pipeline has not attached yet belongs to that function's own tree. Retention stays opt-in twice over: the decompiler records IL steps only when asked to, and the pane asks only while its view is on screen. Every kept step pins the ILAst it captured, which for one type runs to tens of thousands of nodes, so a closed pane would be paying for a tree nobody displays. What is left of the ILAst language is its typed-IL dump, which runs no transforms at all. That stays, as TypedILLanguage. IDebugStepProvider was down to a single implementation and is removed. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	3 weeks ago
Siegfried Pammer	3cb27b0dcc	Fix #3510 : keep exporting a project when a member cannot be decompiled One member the decompiler could not handle aborted the whole export, so a single unsupported method in a large assembly left the user with nothing: no sources, no .csproj, no way around it. Recovering silently would trade that for a worse outcome - broken output nobody knows is broken - so every failure is recorded, written where the content would have gone, and pointed at the issue tracker. The recovery has to hold for anything the export touches, not just method bodies: a file that cannot be created, a resource that cannot be decoded, an output visitor that throws mid-type. Each of those costs its own unit and nothing else, and the units behind a failure are still produced - dropping them would make the export look complete when it is not. Consumers that relied on the exception keep their failure signal: ilspycmd exits non-zero and lists the failures, the PowerShell cmdlets raise an error record per failure, and the round-trip suite asserts the export reported none - otherwise a crash on a method its own tests never call would ship green. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	1 month ago

Author

SHA1

Message

Date

Siegfried Pammer

bb1d830ee6

Fix #2040 : escape BAML strings that XML cannot represent

Obfuscators put arbitrary characters into BAML strings, and XML 1.0 has no
representation for most control characters - a numeric character reference is invalid
for them too. Writing such a document threw ArgumentException from XmlWriter, which
loses the resource on project export and shows an exception instead of the page in the
UI. The escapes are spelled the way the C# output spells them, so one convention covers
both languages. Namespace URIs have to be escaped where the XNamespace is created rather
than in the final pass: the URI is baked into every element name built from it, so
patching only the xmlns declaration would desync the two. Characters XML can carry stay
untouched, so ordinary documents decompile byte-identically.

Every BAML stream of an assembly lives in one .resources container, and the recovery
around resource writing sat outside the loop over its entries, so a single page that
could not be written discarded every other page sharing the container with it.

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

2 weeks ago

Siegfried Pammer

a5bd230e14

Walk the whole decompiler pipeline in the Debug Steps pane

The pane used to split the pipeline across two languages: the ILAst language
stepped the IL transforms, the C# language stepped the AST transforms, and
nothing showed the seam between them, so a step index meant a different thing
depending on which language happened to be selected. Recording both halves into
one Stepper makes an index replayable across the whole pipeline; a limit that
lands in the IL phase has no C# to print, so the halted function is rendered as
ILAst instead.

Which function that is takes some care, because a member group's EndStep is the
next member's first step: a halt standing on a member's opening step belongs to
the member that just finished, a transform that throws where the limit was aimed
has to hand over the ILAst it half-transformed (what the ILAst language showed
as "ILAst after the crash"), and a step recorded on a helper function the
pipeline has not attached yet belongs to that function's own tree.

Retention stays opt-in twice over: the decompiler records IL steps only when
asked to, and the pane asks only while its view is on screen. Every kept step
pins the ILAst it captured, which for one type runs to tens of thousands of
nodes, so a closed pane would be paying for a tree nobody displays.

What is left of the ILAst language is its typed-IL dump, which runs no
transforms at all. That stays, as TypedILLanguage. IDebugStepProvider was down
to a single implementation and is removed.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

3 weeks ago

Siegfried Pammer

3cb27b0dcc

Fix #3510 : keep exporting a project when a member cannot be decompiled

One member the decompiler could not handle aborted the whole export, so a
single unsupported method in a large assembly left the user with nothing: no
sources, no .csproj, no way around it. Recovering silently would trade that
for a worse outcome - broken output nobody knows is broken - so every failure
is recorded, written where the content would have gone, and pointed at the
issue tracker.

The recovery has to hold for anything the export touches, not just method
bodies: a file that cannot be created, a resource that cannot be decoded, an
output visitor that throws mid-type. Each of those costs its own unit and
nothing else, and the units behind a failure are still produced - dropping
them would make the export look complete when it is not.

Consumers that relied on the exception keep their failure signal: ilspycmd
exits non-zero and lists the failures, the PowerShell cmdlets raise an error
record per failure, and the round-trip suite asserts the export reported none
- otherwise a crash on a method its own tests never call would ship green.

Assisted-by: Claude:claude-opus-5[1m]:Claude Code

1 month ago

3 Commits (49ca126fb86729634b20412ff5d07ab294e21221)