ILSpy

9645 Commits

54 Branches

94 Tags

91 MiB

Branch: fix/lambda-parameter-syntax

Commit Graph

Author	SHA1	Message	Date
Siegfried Pammer	7493c5f3d2	Add nuget-top.ps1 to build a corpus from the most-downloaded packages Both tools need a corpus of real assemblies and neither had a way to get one: nugetfuzz-all.ps1 walks the catalog in publish order, which is fine for a crash sweep but makes a poor readability corpus, and the alternative was picking package ids by hand. The ids come from an empty search query, which orders by download count. Downloading them reuses nugetfuzz, which already resolves versions, matches target frameworks and walks the dependency closure into the same cache decompdiff reads; --download-only stops it before it decompiles, since the sweep is the expensive part and a corpus only needs the files. The result is a list of lib directories rather than a single root, because a package already restored on this machine is used from the machine-wide NuGet cache instead of being copied into ours, and a corpus that silently omitted those would misrepresent what was tested. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	3 weeks ago
Siegfried Pammer	d8625ba0ef	Retry transient nuget.org failures instead of filing them as findings A stalled request to nuget.org travelled out of the package run as an unhandled exception, so the report filed it as a decompiler [EXCEPTION] - the one bucket that has to hold nothing but real crashes - and the package was skipped without a single type being decompiled. Seen in the 2026-08-16 sweep, where common.logging.log4net timed out resolving its version list and decompiles clean on a second attempt. A 404 stays immediate: it is an answer, not a flake, and the sweep asks about plenty of ids that are not packages. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	1 month ago
Siegfried Pammer	1da62d9e08	Add TestTools with the nugetfuzz and decompdiff corpus tools Both tools have found real decompiler defects (several merged fixes came out of nugetfuzz sweeps), but they only existed in a private checkout, so nobody else could run them and their setup knowledge lived in one head. They complement the fixture suite from the other side: it decompiles code we wrote, these decompile what the world ships. They stay outside the solution - file-based apps, run by hand, never by CI - and the near-empty Directory.Build.props/Directory.Packages.props keep the repo-wide warnings-as-errors, lock-file and central-package-management settings from reaching them. The catalog sweep driver is PowerShell rather than bash so it runs on Windows as well, which also drops its curl/jq dependency; staging falls back to copying when Windows withholds symlink privileges, and report file names are hash-truncated to stay inside the 260-character path limit. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	1 month ago

Author

SHA1

Message

Date

Siegfried Pammer

7493c5f3d2

Add nuget-top.ps1 to build a corpus from the most-downloaded packages

Both tools need a corpus of real assemblies and neither had a way to get
one: nugetfuzz-all.ps1 walks the catalog in publish order, which is fine for
a crash sweep but makes a poor readability corpus, and the alternative was
picking package ids by hand.

The ids come from an empty search query, which orders by download count.
Downloading them reuses nugetfuzz, which already resolves versions, matches
target frameworks and walks the dependency closure into the same cache
decompdiff reads; --download-only stops it before it decompiles, since the
sweep is the expensive part and a corpus only needs the files.

The result is a list of lib directories rather than a single root, because a
package already restored on this machine is used from the machine-wide NuGet
cache instead of being copied into ours, and a corpus that silently omitted
those would misrepresent what was tested.

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

3 weeks ago

Siegfried Pammer

d8625ba0ef

Retry transient nuget.org failures instead of filing them as findings

A stalled request to nuget.org travelled out of the package run as an unhandled
exception, so the report filed it as a decompiler [EXCEPTION] - the one bucket
that has to hold nothing but real crashes - and the package was skipped without
a single type being decompiled. Seen in the 2026-08-16 sweep, where
common.logging.log4net timed out resolving its version list and decompiles
clean on a second attempt.

A 404 stays immediate: it is an answer, not a flake, and the sweep asks about
plenty of ids that are not packages.

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

1 month ago

Siegfried Pammer

1da62d9e08

Add TestTools with the nugetfuzz and decompdiff corpus tools

Both tools have found real decompiler defects (several merged fixes came out of
nugetfuzz sweeps), but they only existed in a private checkout, so nobody else
could run them and their setup knowledge lived in one head. They complement the
fixture suite from the other side: it decompiles code we wrote, these decompile
what the world ships.

They stay outside the solution - file-based apps, run by hand, never by CI - and
the near-empty Directory.Build.props/Directory.Packages.props keep the repo-wide
warnings-as-errors, lock-file and central-package-management settings from
reaching them.

The catalog sweep driver is PowerShell rather than bash so it runs on Windows as
well, which also drops its curl/jq dependency; staging falls back to copying when
Windows withholds symlink privileges, and report file names are hash-truncated to
stay inside the 260-character path limit.

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

1 month ago

3 Commits (fix/lambda-parameter-syntax)