ILSpy

9782 Commits

54 Branches

94 Tags

91 MiB

Branch: ldmembertoken

Commit Graph

Author	SHA1	Message	Date
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	d978ecf881	Fold the solution export into the shared project-export path Save Code on several assemblies had its own copy of the export flow: its own selection matcher, its own frozen-tab runner, and a hard-coded "Exporting solution" tab title -- so the same operation read differently depending on whether it was started from Save Code or Export Project, which titles the tab after the assemblies. Route it through ProjectExport like the single-assembly path already is, leaving one runner and one matcher behind every flow that decompiles whole assemblies to disk. Save Code keeps letting the user name the .sln (the Export Project dialog only asks for a folder and derives the name from it), so the export options now carry an optional solution file name; unset means the old folder-derived name. Assisted-by: Claude:claude-opus-4-8:Claude Code	2 months ago
Siegfried Pammer	1cebc46c93	Run every Save Code path behind a cancellable progress overlay File -> Save Code decompiled a whole assembly on a bare Task.Run: no progress bar, no way to cancel, and (for a .csproj) diverging from both normal decompilation and the dedicated Export Project command, which already report progress. Route the assembly-save paths through the shared UI instead: - The .csproj export reuses the Export Project machinery (ProjectExporter in a frozen, determinate-progress tab), so a large assembly reports per-file progress and can be cancelled while the tree stays browsable. - The single-file save runs behind the same RunWithCancellation overlay that normal decompilation uses. Both entry points into the project export compute the tab title in one place, titling it after the assemblies being exported (their tree-node labels, joined the way a multi-node decompile tab is) so the tab reads the same whether reached via Save Code or Export Project. Assisted-by: Claude:claude-opus-4-8:Claude Code	2 months ago

Author

SHA1

Message

Date

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

d978ecf881

Fold the solution export into the shared project-export path

Save Code on several assemblies had its own copy of the export flow: its
own selection matcher, its own frozen-tab runner, and a hard-coded
"Exporting solution" tab title -- so the same operation read differently
depending on whether it was started from Save Code or Export Project,
which titles the tab after the assemblies. Route it through ProjectExport
like the single-assembly path already is, leaving one runner and one
matcher behind every flow that decompiles whole assemblies to disk.

Save Code keeps letting the user name the .sln (the Export Project dialog
only asks for a folder and derives the name from it), so the export
options now carry an optional solution file name; unset means the old
folder-derived name.

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

2 months ago

Siegfried Pammer

1cebc46c93

Run every Save Code path behind a cancellable progress overlay

File -> Save Code decompiled a whole assembly on a bare Task.Run: no
progress bar, no way to cancel, and (for a .csproj) diverging from both
normal decompilation and the dedicated Export Project command, which
already report progress. Route the assembly-save paths through the shared
UI instead:

- The .csproj export reuses the Export Project machinery (ProjectExporter
  in a frozen, determinate-progress tab), so a large assembly reports
  per-file progress and can be cancelled while the tree stays browsable.
- The single-file save runs behind the same RunWithCancellation overlay
  that normal decompilation uses.

Both entry points into the project export compute the tab title in one
place, titling it after the assemblies being exported (their tree-node
labels, joined the way a multi-node decompile tab is) so the tab reads
the same whether reached via Save Code or Export Project.

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

2 months ago

3 Commits (ldmembertoken)