Navigating to a target on startup first eagerly loads every relevant
assembly's metadata so the entity search that follows can resolve it.
That pre-load used the throwing GetMetadataFileAsync, so a restored
session that still referenced an assembly whose file had since been
deleted or moved crashed startup with an unhandled
DirectoryNotFoundException instead of simply skipping the gone entry.
Use GetMetadataFileOrNullAsync there: a missing or unreadable assembly
now resolves to null and is skipped, which the entity search already
tolerates (it uses the OrNull variant too).
Assisted-by: Claude:claude-opus-4-8:Claude Code
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
Windows maps CON, PRN, AUX, NUL, COM1-9 and LPT1-9 to devices -- on many
builds even with an extension appended, so a type named Con made both
whole-project export and the save dialog fail with IOException '\\.\Con'.
CleanUpName only checked for reserved names after re-appending the file
extension, where they never match, and the save-dialog default-name
helpers did not check them at all. The escape appends the underscore to
the base name (con_.txt, not con.txt_) because device-name parsing
ignores everything after the first dot, and is applied per path segment
so reserved directory names produced by namespaces are covered too. The
ILSpy.Tests.Windows fixture verifies on a real Windows filesystem that
the escaped names are creatable.
Assisted-by: Claude:claude-fable-5:Claude Code
The File-menu entry was a stub that popped a "not implemented" dialog,
while the working generation logic lived only in the assembly context-
menu entry. Lift that logic into a shared PdbGenerator and route both
entry points through it, so the menu command now generates PDBs for the
selected assemblies (enabled only when the selection holds a valid one).
This was the last NotImplementedDialog caller, so the dialog is removed.
Assisted-by: Claude:claude-opus-4-8:Claude Code
The Export Project/Solution, Save Code and Compare tests decompiled whatever
the default assembly list seeds -- System.Linq, CoreLib, the Uri assembly --
so each spent ~10s purely on type count (Solution/CreateSolution/SaveCode/
DecompileAssembly ~10s, CompareView ~4.5s).
Add FixtureAssembly, which emits a minimal two-type assembly via
PersistedAssemblyBuilder, and point these tests at it. They still exercise the
full project/solution writer, save-to-file and compare-tree pipelines, but
each now runs well under a second (e.g. Solution_Mode 10.8s -> 0.3s,
CreateSolution 10.8s -> 0.2s, ShowIdentical 4.5s -> 0.3s).
Assisted-by: Claude:claude-opus-4-8:Claude Code
Right-click Save Code on a node without a Save() override (type,
namespace, member) did nothing: the context-menu entry only called
node.Save() and stopped when it returned false, unlike Ctrl+S which
falls through to a generic decompile-to-file save. The prior version
always had this fallback in both paths; the port dropped it from the
context entry.
Extract the shared "Save() else decompile the node to a single file"
flow into SaveCodeHelper and route both Ctrl+S and the context-menu
entry through it, targeting the clicked node. As before, the fallback
runs in the active decompiler tab with its progress/cancel overlay and
then shows a "decompilation complete" breadcrumb with an Open-folder
button; the default file name derives from the node's text.
Assisted-by: Claude:claude-opus-4-8:Claude Code
Avalonia has no global ICommand re-query signal like WPF's CommandManager.RequerySuggested, so state-dependent main-menu commands were frozen at their startup CanExecute: a NativeMenuItem only re-reads CanExecute when the command raises CanExecuteChanged, and nothing did. The assembly list is empty when the menu is built, so Clear assembly list was disabled forever; Save and Remove-assemblies-with-load-errors had the same latent bug. Add a weak global CommandManager (held weakly so menu/toolbar items aren't pinned) that SimpleCommand routes CanExecuteChanged through -- exactly as WPF's SimpleCommand routed it -- and invalidate it at the central state-change points: tree selection, the active assembly list, and background-load-sweep completion (so load errors surface). One signal, every platform: NativeMenuItem maps CanExecute onto IsEnabled, which the macOS Cocoa, Linux DBus, and in-window menu exporters all track.
Assisted-by: Claude:claude-opus-4-8:Claude Code
The startup welcome page renders the same About content in the reusable main tab. Help > About opened a second, static About tab beside it, so the user saw the page twice. Track the welcome content and, while it is still the live main-tab content, have Help > About activate it rather than open the singleton. Falls through to the singleton once a tree-node selection has replaced the welcome page.
Assisted-by: Claude:claude-opus-4-8:Claude Code
Tree-node selection now updates the inner Content of one persistent
ContentTabPage instead of swapping the dockable in the dock. The
wrapper view (ContentTabPageView) keeps both inner views — the
decompiler text editor and the metadata grid — pre-realised in the
visual tree from construction time and toggles which is visible based
on Content's runtime type.
Assisted-by: Claude:claude-opus-4-7:Claude Code
Replaces the brittle root.GetVisualDescendants().OfType<T>().Single() / .First()
pattern with a new WaitForComponent<T>() extension that polls until the requested
control is in the visual tree, then returns it. Avalonia.Headless tests routinely
queried the visual tree before lazily-templated panes (DataGrid, dock content)
had materialised, surfacing as intermittent 'Sequence contains no elements'
failures across the suite.
Assisted-by: Claude:claude-opus-4-7:Claude Code
AvaloniaEdit's TextEditorOptions.RequireControlModifierForHyperlinkClick
only flows into its *built-in* LinkElementGenerator (via the
IBuiltinElementGenerator.FetchOptions hook the editor calls from
UpdateBuiltinElementGeneratorsFromOptions). Subclasses added to
ElementGenerators by hand inherit whatever the parameterless base
constructor sets — which is "true" — so the editor-level flag flipped in
DecompilerTextView didn't actually reach our generator.
Assisted-by: Claude:claude-opus-4-7:Claude Code
Each tree-expansion, selection change, command execution, async wait and
key/mouse injection inside an [AvaloniaTest] now carries a short imperative
comment on the line above (e.g. "// expand typeNode", "// select methodA",
"// wait for assemblies to load", "// execute aboutCmd"). The comments are
the same scaffolding the manual debug-with-screenshot workflow uses to
follow what's happening at each breakpoint, surfaced into the committed
source so the tests are readable without the breakpoint markers attached.
Assisted-by: Claude:claude-opus-4-7:Claude Code
CommandLineArguments was already parsed at App.OnFrameworkInitializationCompleted
but never read. AssemblyTreeModel grows HandleCommandLineArgumentsAsync that
applies the parsed values:
Assisted-by: Claude:claude-opus-4-7:Claude Code
Flips Editor.Options.RequireControlModifierForHyperlinkClick to false in
DecompilerTextView's constructor — that's the value AvaloniaEdit's built-in
LinkElementGenerator forwards onto every VisualLineLinkText it constructs,
so toggling it once at the editor level removes the Ctrl requirement for
every hyperlink in the decompiled output (in-app references, About-page
resource links, future external URLs alike).
Assisted-by: Claude:claude-opus-4-7:Claude Code
Generalises NavigationHistory<SharpTreeNode> into NavigationHistory<NavigationEntry>
with two subtypes — TreeNodeEntry (a tree-node selection in a specific tab)
and StaticPageEntry (a static page like About in a specific tab) — mirroring
the WPF host's NavigationState/ViewState pair.
Assisted-by: Claude:claude-opus-4-7:Claude Code
Replaces the previous WriteReference(string, Uri) approach with a
LinkElementGenerator subclass that scans the rendered document for the
target phrases ("MIT License" / "third-party notices"), matching the
WPF host's MyLinkElementGenerator pattern. The custom generator collection
travels through AvaloniaEditTextOutput → DecompilerTabPageModel.
CustomElementGenerators → DecompilerTextView (which installs and tears
them down per ApplyDocument).
Assisted-by: Claude:claude-opus-4-7:Claude Code
The "MIT License" and "third-party notices" phrases inside the About blurb
now write as ReferenceSegments carrying resource: URIs instead of plain
text. The new tab subscribes to NavigateRequested and opens the embedded
LICENSE / third-party-notices.txt content in a new tab on click.
Assisted-by: Claude:claude-opus-4-7:Claude Code
Replaces the NotImplementedDialog stub with a real AboutCommand that builds
an AvaloniaEditTextOutput (ILSpy version, .NET version, embedded
ILSpyAboutPage.txt) and routes it through DockWorkspace.OpenNewTab as a
DecompilerTabPageModel. Adds an IAboutPageAddition extension point so future
plugins can append to the page. ILSpyAboutPage.txt / third-party-notices.txt
/ LICENSE are embedded via the same shape WPF uses.
Assisted-by: Claude:claude-opus-4-7:Claude Code
Siegfried Pammer