pimhwang/ILSpy - ILSpy - git.quantfans.net

Author	SHA1	Message	Date
Siegfried Pammer	a9d7538eef	Show real progress while a solution exports Solution export reported once per assembly, when that assembly finished. Nothing was reported before the first one did, so the tab sat on the indeterminate spinner it starts with for most of the run and then jumped straight to the end -- exporting two assemblies showed a spinner, 1 of 2, done. A project that bailed out before decompiling never reported at all, stranding the bar short of the end for the rest of the export. Sum the per-project file counts instead: each parallel worker feeds its own counts into a shared map and the bar reports their total. WholeProjectDecompiler carries its whole file count on every report, so the total is known from a project's first written file rather than its last -- measured on two real assemblies, the bar turns determinate after 245ms instead of 15s, and moves through 978 files rather than 2 assemblies. Each project closes its share out in a finally, so bailing out or cancelling still lets the bar reach the end. The denominator grows over the first second as projects discover their file counts. The alternative -- enumerating every project's types up front -- delays the export itself to make the bar look better, which is the wrong trade. Assisted-by: Claude:claude-opus-4-8:Claude Code	2 months ago
Siegfried Pammer	150fa30aa3	Export what loaded, and let the user name the solution Two gaps in the export paths, both visible from the same selection. A selection holding an assembly that failed to load was turned away by TryGetExportableAssemblies, so Ctrl+S fell through to the single-node save and quietly wrote just the focused assembly -- the rest of the selection vanished with no report. The predicate now only insists that something in the selection loaded, and the exporter skips what it cannot decompile and names it in the status report. That is also what the dialog always assumed: its "not a valid assembly" row badge was unreachable, because no selection containing one could get that far. The dialog asks for an output folder and derived the .sln name from it, while Save Code lets the user name the file. Now the dialog offers the name too, in solution mode, defaulting (via the placeholder) to the folder- derived name the exporter would pick anyway. Assisted-by: Claude:claude-opus-4-8:Claude Code	2 months ago
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	3 months ago
Siegfried Pammer	f44697cb38	Show live progress in long-running operation tabs Project/solution export (and other RunInNewTabAsync work) opened a tab with a static title and a permanently indeterminate progress bar, even though the whole-project decompiler already produces per-file DecompilationProgress that was being dropped. Wire that progress through: DecompilationOptions carries an IProgress<DecompilationProgress> that DecompileAsProject sets on the WholeProjectDecompiler; a new RunInNewTabAsync overload hands the work a UI-thread-marshaled Progress<T> feeding the tab. The tab now animates the braille spinner over its title (the operation name) and shows a determinate bar plus the file currently being written and an "N of M" count. Solution export reports per-assembly rather than per-file, since its assemblies decompile in parallel and per-file reports would race. The determinate bar is pinned to 75% of the overlay width so it doesn't jitter as the status text changes. Assisted-by: Claude:claude-opus-4-8:Claude Code	3 months ago
Siegfried Pammer	aa92f27e09	Decompile a tiny emitted fixture in the project-export/save/compare tests 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	3 months ago
Siegfried Pammer	60405af407	Add a configurable Export Project/Solution dialog The quick Save Code path exports a project (one assembly) or a solution (several) straight through a file picker, with no way to tune the output. Add a dedicated, discoverable "Export Project/Solution..." entry (File menu + assembly context menu, alongside Save Code) that opens a configuration dialog: pick the output folder, preview the projects that will be written (with invalid / duplicate-name / PDB-eligible badges), toggle project-format and decompiler options, optionally sign with a strong-name key, and optionally emit a portable PDB per assembly -- defaulting source-embedding off since the project's .cs are on disk. The export runs on a clone of the live settings (never the persisted instance) behind the tab's cancellable progress UI and reports into the active decompiler tab. StrongNameKeyFile now flows through DecompilationOptions into the project writer, which had no reachable setter before. The engine (ProjectExporter) and the preview computation are split out from the window so they are headless-testable. Assisted-by: Claude:claude-opus-4-8:Claude Code	3 months ago