ILSpy

9782 Commits

54 Branches

94 Tags

91 MiB

Branch: ldmembertoken

Commit Graph

Author	SHA1	Message	Date
Christoph Wille	16cd684a09	Replace the process dialog's grids with ListBoxes ProDataGrid derives its scroll extent from the current scroll offset, so an offset that is briefly too large inflates the extent, which permits a larger offset again. A trackpad reaches that state within a few hundred sub-row events: instrumented in the running app, a ~1500px list reported 8735px and kept growing, the thumb collapsed to its minimum, and the end of the list ran away from the user. A second defect slid the rows sideways by up to 10px - the star-sized column is measured against the width including the vertical scroll bar, leaving the grid convinced it has a scroll bar's worth of content to reach. Disabling the horizontal scroll bar, giving each grid its own DefaultRowHeightEstimator, pinning RowHeight, forcing the vertical scroll bar visible, and disabling scrolling on the template's inner ScrollViewer each removed a symptom at most; none can break a loop that runs through the scroll offset, and 12.0.4 is the newest release. A ListBox's virtualizing panel keeps the extent a function of the items alone. The price is laying out the columns here - so the header row and the item template have to be kept in step - and losing sortable, resizable headers. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	2 months ago
Christoph Wille	d6bf916398	Fix unreachable-process and selection defects in the process dialog A refused unix socket raises SocketException, which derives from Win32Exception rather than IOException, so it escaped the filter meant to skip one unreachable process and failed the whole concurrent enumeration instead: a machine where any .NET process exits between the port scan and the connect showed an empty list. The classification is now a named predicate covering both transports. Two dialog defects shared a shape - state left behind by a query nobody is waiting for any more. Rebuilding the bound collection on every filter keystroke made the grid drop its selection and write that null back, discarding the assemblies of a process the new filter still matched; and the branch taken when nothing is selected cleared no loading flag, while the query it superseded was no longer allowed to, so the progress bar animated over an empty pane. Relatedly, the two-second command budget expired into a process listed with null metadata, which made a slow machine look like a runtime that answered with nothing; it is longer now, and expiry names the process it gave up on, since the only thing that ever reaches the far end of that budget is a runtime which will never answer. The test gaps are closed the same way: a real dynamic assembly pins the in-memory classification, the managed-only assertion is stated as the property instead of a list of native names to exclude, and the .NET Framework path gets live tests. Those showed that a desktop CLR process mostly reports NGen native images rather than the IL assemblies behind them, which is now recorded as the fidelity gap it is. Assisted-by: Claude:claude-opus-5:Claude Code	2 months ago
Christoph Wille	719e863679	Add "Open from running process" dialog With a modern .NET app the executable in the process list is a native apphost that carries no IL, so the path a user can see is precisely the one a decompiler cannot open - ILSpy itself is an example. Ask the runtime instead: since .NET Core 3.0 every CoreCLR process serves a diagnostics endpoint that names its managed entry assembly and, via an EventPipe rundown, every assembly it has loaded, including ones behind a single-file bundle or with no file at all. The endpoint answers the same way on Windows, Linux and macOS and needs no privileges beyond same-user, which also makes it the only workable route on macOS, where native process introspection is gated by SIP. The protocol and the nettrace container it returns are implemented here rather than taken from Microsoft.Diagnostics.NETCore.Client, so the feature costs no new package reference; the reader is scoped to loader rundown events and steps over everything else by size. The rundown asks for the loader keyword alone: the runtime's default set also collects the JIT and IL-to-native-map rundown, which in a long-running process buries the module list and overruns the session buffer, costing the very events the dialog needs. Windows additionally lists .NET Framework processes, which predate the endpoint and are read from their OS module list instead. Assisted-by: Claude:claude-fable-5:Claude Code	2 months ago

Author

SHA1

Message

Date

Christoph Wille

16cd684a09

Replace the process dialog's grids with ListBoxes

ProDataGrid derives its scroll extent from the current scroll offset, so an
offset that is briefly too large inflates the extent, which permits a larger
offset again. A trackpad reaches that state within a few hundred sub-row
events: instrumented in the running app, a ~1500px list reported 8735px and
kept growing, the thumb collapsed to its minimum, and the end of the list ran
away from the user. A second defect slid the rows sideways by up to 10px - the
star-sized column is measured against the width including the vertical scroll
bar, leaving the grid convinced it has a scroll bar's worth of content to
reach.

Disabling the horizontal scroll bar, giving each grid its own
DefaultRowHeightEstimator, pinning RowHeight, forcing the vertical scroll bar
visible, and disabling scrolling on the template's inner ScrollViewer each
removed a symptom at most; none can break a loop that runs through the scroll
offset, and 12.0.4 is the newest release. A ListBox's virtualizing panel keeps
the extent a function of the items alone. The price is laying out the columns
here - so the header row and the item template have to be kept in step - and
losing sortable, resizable headers.

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

2 months ago

Christoph Wille

d6bf916398

Fix unreachable-process and selection defects in the process dialog

A refused unix socket raises SocketException, which derives from
Win32Exception rather than IOException, so it escaped the filter meant to
skip one unreachable process and failed the whole concurrent enumeration
instead: a machine where any .NET process exits between the port scan and
the connect showed an empty list. The classification is now a named
predicate covering both transports.

Two dialog defects shared a shape - state left behind by a query nobody is
waiting for any more. Rebuilding the bound collection on every filter
keystroke made the grid drop its selection and write that null back,
discarding the assemblies of a process the new filter still matched; and the
branch taken when nothing is selected cleared no loading flag, while the
query it superseded was no longer allowed to, so the progress bar animated
over an empty pane. Relatedly, the two-second command budget expired into a
process listed with null metadata, which made a slow machine look like a
runtime that answered with nothing; it is longer now, and expiry names the
process it gave up on, since the only thing that ever reaches the far end of
that budget is a runtime which will never answer.

The test gaps are closed the same way: a real dynamic assembly pins the
in-memory classification, the managed-only assertion is stated as the
property instead of a list of native names to exclude, and the .NET
Framework path gets live tests. Those showed that a desktop CLR process
mostly reports NGen native images rather than the IL assemblies behind them,
which is now recorded as the fidelity gap it is.

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

2 months ago

Christoph Wille

719e863679

Add "Open from running process" dialog

With a modern .NET app the executable in the process list is a native
apphost that carries no IL, so the path a user can see is precisely the
one a decompiler cannot open - ILSpy itself is an example. Ask the
runtime instead: since .NET Core 3.0 every CoreCLR process serves a
diagnostics endpoint that names its managed entry assembly and, via an
EventPipe rundown, every assembly it has loaded, including ones behind a
single-file bundle or with no file at all. The endpoint answers the same
way on Windows, Linux and macOS and needs no privileges beyond same-user,
which also makes it the only workable route on macOS, where native
process introspection is gated by SIP.

The protocol and the nettrace container it returns are implemented here
rather than taken from Microsoft.Diagnostics.NETCore.Client, so the
feature costs no new package reference; the reader is scoped to loader
rundown events and steps over everything else by size. The rundown asks
for the loader keyword alone: the runtime's default set also collects the
JIT and IL-to-native-map rundown, which in a long-running process buries
the module list and overruns the session buffer, costing the very events
the dialog needs.

Windows additionally lists .NET Framework processes, which predate the
endpoint and are read from their OS module list instead.

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

2 months ago

3 Commits (ldmembertoken)