Skip to content

Add TestTools with the nugetfuzz and decompdiff corpus tools - #4020

Open
siegfriedpammer wants to merge 2 commits into
masterfrom
testtools
Open

Add TestTools with the nugetfuzz and decompdiff corpus tools#4020
siegfriedpammer wants to merge 2 commits into
masterfrom
testtools

Conversation

@siegfriedpammer

Copy link
Copy Markdown
Member

Adds TestTools/, two standalone tools that run the decompiler over real-world
assemblies. They complement the fixture suite from the other side: it decompiles
code we wrote, these decompile what the world ships.

tool question it answers
nugetfuzz.cs Does the decompiler crash on real code? (asserts, exceptions, IL warnings)
decompdiff.cs Did a change make the output better or worse? (readability across two builds)

Several merged fixes came out of nugetfuzz sweeps (#3958, #3959, #3960, #3961),
but the tools only existed in a private checkout, so nobody else could run them
and their setup knowledge lived in one head.

Both are file-based apps:
single .cs files run with dotnet run <file>.cs. They are in no solution and
not run by CI. The near-empty Directory.Build.props / Directory.Packages.props
stop MSBuild's upward search, so the repo-wide warnings-as-errors, lock-file and
central-package-management settings do not reach them (central package management
in particular rejects the inline #:package version).

nugetfuzz-all.ps1, the catalog sweep driver, is PowerShell rather than bash so
it runs on Windows too, which also drops its curl/jq dependency. Two further
Windows adjustments: decompdiff 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.

TestTools/README.md documents usage, the reference-assembly handling and the
platform notes.

Verified on Linux: both tools build in-repo; a one-page/one-package sweep runs the
full download/decompile/ledger cycle; decompdiff 9.1 vs 11.0-preview over
ICSharpCode.Decompiler.dll reports 75 changed types with non-empty inline diffs.
The Windows-specific paths are code-path fixes, not a tested run.

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
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants