A finding is recorded before the reference context exists, because the resolver
keeps discovering references until the assembly is done. An assembly that fails
in the type system returns without ever reporting its resolutions, so its keys
stayed pending and the next assembly stamped its own reference set onto them.
Naming the wrong references is worse than naming none, in a report that is read
precisely to tell a reference problem from a decompiler defect.
Assisted-by: Claude:claude-opus-5:Claude Code
A finding named the package, the assembly's file name and the type, which is
not enough to reproduce it: the assembly lives in a version-specific cache
directory, and the references it was decompiled against are the whole question
whenever a warning turns out to be a reference problem rather than a defect.
That judgement had to be made by rerunning the package under NUGETFUZZ_VERBOSE
and reading the console, which the ledger of a catalog sweep cannot offer at
all.
The reference set is captured once the assembly is finished rather than when a
finding is first hit. The resolver keeps discovering references for as long as
it decompiles, so a finding from the first type would otherwise record a set
that is mostly still empty.
Ledger lines written before this field existed deserialize with it empty and
render as they did.
Assisted-by: Claude:claude-opus-5:Claude Code
A sweep covers thousands of packages, and the same simple assembly name
ships in many of them and in several TFM folders of a single package, so
a finding keyed on the file name alone cannot be traced back to the
assembly it came from.
Assisted-by: Claude:claude-opus-5:Claude Code
decompdiff counted the substring "<>" in the output text, which both missed
mangled names that do not contain it ("VB$AnonymousType_0", "<Main>$") and
counted every generic argument list ending in an identifier character. The
shape is matched lexically there because only text is available; nugetfuzz has
the syntax tree, so it applies the decompiler's own identifier rule
(EscapeInvalidIdentifiers.IsValid) to the tree's identifiers instead, and any
hit is output that does not compile. Findings collapse to the shape of the
name because the bracketed part and the digits vary per occurrence, so one
unfolded construct stays one finding rather than one per member it hit.
The report's kind list is also the render loop's only source of sections, so
the PDB bucket added with the PDB verification mode never reached the HTML.
Assisted-by: Claude:claude-opus-5:Claude Code
The PDB writer had no coverage beyond hand-written fixtures whose sequence
points are compared to the compiler's, and nothing ever asked whether a
consumer can read what it emits. Issue #2823 is the consequence: a PDB that
loads fine in ILSpy kills ILLink, and it took a reporter's own tool to find
out.
--pdb reuses the corpus, download and reference-pack machinery already in
nugetfuzz and replaces the type sweep with two checks: Mono.Cecil - the
consumer ILLink uses - has to read every method body through the generated
PDB, and a lint has to find everything the PDB claims true of the assembly.
--pdb-lint exists because a lint is only worth its findings if it is silent
on correct input. It runs the same checks against a PDB the compiler wrote,
and three of the checks written here were wrong until it said so - including
the async one, which flagged the compiler's own PDB for any executable with
an async Main, a case 190 nuget packages could not contain because a library
has no entry point.
Assisted-by: Claude:claude-opus-5:Claude Code
Resolving one assembly resolves its whole reference closure, and every
reference in it asked the same framework directories the same questions.
The worst of it was the scan for the closest version folder of a shared
framework: a directory listing plus a recursive file search, repeated per
reference and per runtime pack - 42 scans for two distinct answers when
decompiling ICSharpCode.ILSpyX.dll.
The scan result is only safe to keep for a bounded time: a runtime can be
installed or removed while ILSpy runs, and reloading an assembly list has
to see that. So it is kept for the length of an explicitly opened scope,
which the type system opens around the closure it resolves and closes
again afterwards; outside a scope the file system is read as before. The
scope owns what was read, so two of them on one resolver do not stack -
the first to end takes it, and the other reads the file system again.
BeginSnapshot is on IAssemblyResolver rather than an interface of its
own: it is core functionality of a resolver, and one implementation is
not an abstraction. This breaks the interface for implementors outside
this repository, who opt out by returning null - which is what the three
resolvers here that hold nothing do.
The remaining probes cost nothing to fix: the preferred runtime pack was
listed among the defaults it already belongs to, so its directory was
scanned twice for every reference that is not in it, and one package
folder was probed once per assembly the package contains.
Measured over 27 references with a fresh resolver each time: 3.3 ms per
assembly before, 3.1 ms without a scope, 1.1 ms with one.
Assisted-by: Claude:claude-opus-5:Claude Code
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
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
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
Siegfried Pammer