pimhwang/ILSpy - ILSpy - git.quantfans.net

Author	SHA1	Message	Date
Siegfried Pammer	56f639b615	Read a decompdiff corpus from an @list file Handing the corpus over as `$(cat list)` is a bourne shell construct, so the one invocation the tools print and the README documents did not work on Windows. nugetfuzz already reads its package list from an @file for the same reason; decompdiff now takes its corpus entries the same way, leaving the shell out of it entirely. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	3 weeks ago
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	f440f28301	Accept a commit-ish as a decompdiff side Comparing two commits meant preparing a worktree for each by hand before the tool could be called, which is most of the work of running it and easy to get wrong: a checkout carrying a stale Release build is reused silently, and the timestamp in the header line was the only thing that said so. --old and --new now also take anything git can resolve to a commit, checked out into a worktree under ~/.cache/decompdiff keyed by that commit. The worktrees are kept because the Release build inside one is what a rerun would otherwise repeat: a second run of the same pair drops from minutes to seconds. Paths keep priority over refs, so an existing directory never changes meaning. Assisted-by: Claude:claude-opus-5[1m]:Claude Code	3 weeks ago
Siegfried Pammer	0f4bb196e6	Bind each corpus assembly against its own reference-assembly pack decompdiff indexed the Microsoft.NETFramework.ReferenceAssemblies packs into one flat name map shared by the whole corpus, and never indexed Microsoft.NETCore.App.Ref at all. Ordering the packs by name let net45 claim mscorlib and System.Runtime, so a net9.0 assembly resolved its BCL against .NET Framework 4.5: Task, ValueTask and the async method builders came back as UnknownType, AsyncAwaitDecompiler could not match a state machine, and every async method decompiled as a raw MoveNext. Both sides of a diff degraded identically, so comparisons stayed valid, but the corpus stopped representing modern code. Over 28 nuget assemblies the same run reports 338 //IL_ warnings instead of 18202, 237 leaked <> names instead of 15654, and 116k fewer lines. The pack is now chosen per assembly from its TargetFrameworkAttribute and searched before anything else, matching how nugetfuzz already resolves them. 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