ILSpy

9187 Commits

24 Branches

90 Tags

71 MiB

Tree: 3f32d4a5e9

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	51aafa0fd9	Move ILSpy UI code back to the ICSharpCode.ILSpy root namespace The Avalonia port had placed the UI app in an ILSpy.* namespace tree, while the csproj RootNamespace and every prior release (through 10.1) use ICSharpCode.ILSpy.*. Restoring the historical namespace reduces the public API diff against release/10.1 for plugin authors and removes the shadowing that forced global:: qualifiers in the test project. The Images class and AccessOverlayIcon enum move back into the root namespace (as in 10.1), since an ICSharpCode.ILSpy.Images namespace would shadow the Images class for all code inside ICSharpCode.ILSpy. Assisted-by: Claude:claude-fable-5:Claude Code	4 weeks ago
Siegfried Pammer	93db1041b1	Decompile a single method in the slow Options tests Two Options tests selected the whole System.Linq.Enumerable type and then awaited WaitForDecompiledTextAsync. That decompile takes >15 s in headless and overran the 60 s wait on a loaded CI runner, so the suite flaked intermittently (green in one run of a commit, red in another). The behaviours under test -- that a re-decompile setting refreshes the active tab, and that the refresh does not steal focus from the Options tab -- fire on whatever the tab shows, so a single small method exercises them just as well and decompiles near-instantly. Assisted-by: Claude:claude-opus-4-8:Claude Code	4 weeks ago
Siegfried Pammer	4ab76f47e7	Re-decompile the active tab on output display-setting changes The Options page is non-modal and live-apply, so -- unlike the WPF host, which ran a full assembly-list Refresh() when its modal Options dialog closed -- a setting that changes the decompiler/disassembler output (brace folding, member/using expansion, debug info, IL detail, indentation) had nothing to make it take effect; toggling it did nothing until the user re-navigated. Classify every DisplaySettings property in one table (DisplaySettingReactions: editor-live / tree-text / tree-shape / re-decompile / none), grounded in the actual consumers (ApplyDisplaySettings, GetIndentationString, the IL/mixed languages). OnSettingsChanged dispatches on it, and a coverage test asserts the table spans every settable property so a newly-added one can't silently fall through. Fixing the re-decompile case exposed that ForceRefreshActiveTab was itself a no-op for an unchanged node -- ShowSelectedNode re-sets CurrentNodes, whose setter dedups -- so RefreshDecompiledView (also used after dependency resolution) never actually re-ran. Add DecompilerTabPageModel.Redecompile() to force past the dedup and call it from ForceRefreshActiveTab. Also drop the EnableSmoothScrolling setting: it drove TomsToolbox's AdvancedScrollWheelBehavior in WPF, which the Avalonia port doesn't use and never replaced, so the checkbox persisted a value nothing read. Assisted-by: Claude:claude-opus-4-8:Claude Code	4 weeks ago

Author

SHA1

Message

Date

Siegfried Pammer

51aafa0fd9

Move ILSpy UI code back to the ICSharpCode.ILSpy root namespace

The Avalonia port had placed the UI app in an ILSpy.* namespace tree,
while the csproj RootNamespace and every prior release (through 10.1)
use ICSharpCode.ILSpy.*. Restoring the historical namespace reduces the
public API diff against release/10.1 for plugin authors and removes the
shadowing that forced global:: qualifiers in the test project. The
Images class and AccessOverlayIcon enum move back into the root
namespace (as in 10.1), since an ICSharpCode.ILSpy.Images namespace
would shadow the Images class for all code inside ICSharpCode.ILSpy.

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

4 weeks ago

Siegfried Pammer

93db1041b1

Decompile a single method in the slow Options tests

Two Options tests selected the whole System.Linq.Enumerable type and then
awaited WaitForDecompiledTextAsync. That decompile takes >15 s in headless and
overran the 60 s wait on a loaded CI runner, so the suite flaked intermittently
(green in one run of a commit, red in another). The behaviours under test --
that a re-decompile setting refreshes the active tab, and that the refresh does
not steal focus from the Options tab -- fire on whatever the tab shows, so a
single small method exercises them just as well and decompiles near-instantly.

Assisted-by: Claude:claude-opus-4-8:Claude Code

4 weeks ago

Siegfried Pammer

4ab76f47e7

Re-decompile the active tab on output display-setting changes

The Options page is non-modal and live-apply, so -- unlike the WPF host,
which ran a full assembly-list Refresh() when its modal Options dialog
closed -- a setting that changes the decompiler/disassembler output (brace
folding, member/using expansion, debug info, IL detail, indentation) had
nothing to make it take effect; toggling it did nothing until the user
re-navigated.

Classify every DisplaySettings property in one table (DisplaySettingReactions:
editor-live / tree-text / tree-shape / re-decompile / none), grounded in the
actual consumers (ApplyDisplaySettings, GetIndentationString, the IL/mixed
languages). OnSettingsChanged dispatches on it, and a coverage test asserts
the table spans every settable property so a newly-added one can't silently
fall through.

Fixing the re-decompile case exposed that ForceRefreshActiveTab was itself a
no-op for an unchanged node -- ShowSelectedNode re-sets CurrentNodes, whose
setter dedups -- so RefreshDecompiledView (also used after dependency
resolution) never actually re-ran. Add DecompilerTabPageModel.Redecompile()
to force past the dedup and call it from ForceRefreshActiveTab.

Also drop the EnableSmoothScrolling setting: it drove TomsToolbox's
AdvancedScrollWheelBehavior in WPF, which the Avalonia port doesn't use and
never replaced, so the checkbox persisted a value nothing read.

Assisted-by: Claude:claude-opus-4-8:Claude Code

4 weeks ago

3 Commits (3f32d4a5e943d7ef869f22ae9fcb5814d84537da)