The Windows job runs every test host of the solution concurrently on a
4-core runner. With ICSharpCode.Decompiler.Tests on server GC that host
sits at 98-100% CPU for the whole test step, and the neighbours starve:
the process-module walk in ILSpy.Tests.Windows exceeded its 60 s budget
(OperationCanceledException in NetFrameworkProcessesTests, Release job),
a background sampler measured its own walk over the ~170 runner processes
at 40-170 s instead of a few seconds, and ILSpy.Tests took 685 s instead
of 375 s (Release). Memory was not the constraint: never below 9 GB free,
disk idle. The decompiler suite itself moved little on that box (Debug
1393 s -> 1226 s, Release 664 s -> 751 s). Server GC stays on for machines
the suite has to itself; the Linux job runs the projects one at a time.
Assisted-by: Claude:claude-fable-5:Claude Code
* Set v11 RTM
* Update features in README.md
* Remove the two 900-iteration process-list scroll tests
* Keep Svg.Controls.Skia.Avalonia at 12.0.0.13
* 10.0.11 and Roslyn for net11p7
* Fix module-scan test failing when PowerShell's NGen images are stale
* Opt Pack NuGets out of the MSBuild server to fix SBOM generation
The decompiler suite is cross-platform code already exercised by the
Windows and Linux jobs; running it a third time on macOS only made the
slowest job of the matrix (~54 min vs ~41 min on Linux) slower without
adding coverage.
Assisted-by: Claude:claude-fable-5:Claude Code
The gate job was copy-pasted into build-ilspy.yml and build-frontends.yml
and the two copies had already started drifting (job casing, comment
wording). A workflow_call workflow keeps a single definition; the callers
shrink to a uses: job and route its "run" output to their build jobs
unchanged. Each caller must still grant pull-requests: read explicitly,
because the called workflow's token is the intersection of what the
caller grants and what the callee requests, and both callers default to
contents: read only.
Assisted-by: Claude:claude-fable-5:Claude Code
A branch with an open PR was built twice per push, once by the push
trigger and once by the pull_request trigger, doubling the Actions cost
of every PR iteration. The pull_request run is the canonical one (it
tests the merge with the base branch), so a small gate job now asks the
API whether the pushed branch has an open PR whose base would fire the
pull_request trigger and skips the push build if so. Pushes to master
and release/* are exempt because their runs publish packages; PRs
targeting other branches are ignored because they never trigger a
pull_request build that could replace the push one.
Filtering fork PRs in the on: section instead was considered and
rejected: trigger-level filters cannot see whether an open PR exists,
and skipping the pull_request runs would have lost merge testing.
Assisted-by: Claude:claude-fable-5:Claude Code
Decompiling one method or property previously required decompiling its
whole type and searching the output, which is wasteful for scripted and
agent-driven use against large assemblies. The new -m|--member option
accepts an XML documentation id string (the syntax of compiler-generated
documentation files and of the UI's --navigateto option) or a metadata
token in 0x06000005 form, resolves it against the main module (with a
bounds check for tokens and distinct error messages for malformed ids,
unknown members, and members of other modules), and prints just that
member through the engine's single-member decompilation path.
The tests seed a new ICSharpCode.ILSpyCmd.Tests project (part of the
XPlat and Desktop solution filters and of the per-project CI test
steps), driving the real Main in-process via InternalsVisibleTo, so
future ilspycmd features have a dedicated home for CLI tests.
Assisted-by: Claude:claude-fable-5:Claude Code
The BAML tests were orphaned: in no solution, no CI, and missing their
ICSharpCode.BamlDecompiler reference. Revive them split by platform,
mirroring ILSpy.Tests / ILSpy.Tests.Windows: ILSpy.BamlDecompiler.Tests
(net11.0) holds platform-agnostic tests - including a regression test that
decompiles with the WPF assemblies hidden, covering the missing-assembly
fix - and ILSpy.BamlDecompiler.Tests.Windows (net11.0-windows) holds the
WPF round-trip cases that compile XAML into BAML. Single-TFM projects keep
normal lock files; the Windows one declares all RIDs so its lock is
generatable and verifiable on any host.
Wire the cross-platform project into ILSpy.sln, ILSpy.XPlat.slnf and
ILSpy.Desktop.slnf so it builds and runs on the Linux/macOS legs; the
Windows project stays in ILSpy.sln (its tests execute in the Windows leg).
The Windows job also archives that assembly, whose embedded BAML lets the
decompiler be exercised against real BAML on a host without WPF.
Assisted-by: Claude:claude-opus-4-8:Claude Code
Failed decompiler-test runs leave their generated fixtures (compiled
test assemblies, generated IL, diff inputs) on the runner where they
are lost, making CI-only failures hard to diagnose. Capture the folder
via upload-artifact's own client-side zip at compression-level 9
instead of a separate 7z step, since 7z is not reliably available on
the macOS runner.
Assisted-by: Claude:claude-fable-5:Claude Code
* Migrate ILSpy.AddIn.VS2022 to SDK-style VSIX project
* Retire the legacy VS2017/2019 ILSpy add-in
* Build the VS extension via dotnet build on the slnx
* Inline ILSpy.AddIn.Shared into ILSpy.AddIn.VS2022
* Restore the VS add-in menus broken by the SDK-style migration
The Linux and macOS jobs were near-identical copies; their shared head
(checkout, SDK setup, version, restore, build, both test steps, test-log
upload) drifts the moment one is edited and the other is not. Collapse
them into a single platform-parameterized matrix job, and hoist the .NET
SDK version/quality and the staging directory to workflow-level env so an
SDK bump is a one-line change across all jobs.
The Windows job keeps its id (Build) so internal references stay stable,
but gains a display name to read as "Desktop (Windows)" alongside the
matrix "Desktop (linux)/(macos)" checks. Branch-protection required
checks must be repointed to the new check names.
Assisted-by: Claude:claude-opus-4-8:Claude Code
The decompiler test suite is platform-aware: on non-Windows,
Tester.SupportedOnCurrentPlatform keeps only the dotnet-hosted Roslyn
configs and [Platform("Win")] gates the fixtures that truly need
Windows (legacy csc, mcs, 32-bit, roundtrip), so running the suite on
the Linux and macOS jobs gives real coverage of the non-Windows
decompilation paths instead of leaving them untested. Both jobs now
also check out the ILSpy-tests submodule, because the TargetNet40
configs compile against its legacy reference assemblies even when the
compiled output is never executed.
Assisted-by: Claude:claude-fable-5:Claude Code
Two new jobs run alongside the Windows matrix: each builds the desktop
solution filter on its own OS, runs the headless UI tests there, and
packages Release self-contained bundles (zip/deb/rpm on Linux, zipped
ILSpy.app on macOS) via the BuildTools packaging scripts. Decompiler
tests, NuGet packing, and the Windows installers stay in the Windows
job, and neither new job checks out the ILSpy-tests submodule, since
that only feeds the decompiler tests. The Windows job is untouched so
existing required-status-check names keep working.
Assisted-by: Claude:claude-fable-5:Claude Code
In pwsh the bare '-xr!*.pdb' 7z argument is split into two tokens, '-xr!*'
(which excludes everything) and a bogus '.pdb' source, so the Release
binaries zip added 0 files and the step failed. Quote the exclusion so it
reaches 7z as one token, and pin the job's run shell to pwsh via defaults
so no step silently inherits a different default shell.
Assisted-by: Claude:claude-opus-4-8:Claude Code
The Pdb2Xml command (ILSpy) and the PDB round-trip tests (Decompiler.Tests)
reference Microsoft.DiaSymReader*, previously gated on the build host being
Windows. That made dotnet restore resolve a different graph on Windows than
on Linux -- the packages (and their transitive tail: DiaSymReader.PortablePdb,
the legacy NETCore.Platforms/Win32 packages) appear only on Windows, and
DiaSymReader.Native flips between Direct and CentralTransitive. So a checkout
could not be developed across OSes without the committed packages.lock.json
churning on every Windows restore.
Drop the OS gate (keep Debug-only) so the restored graph, and the committed
lock, are identical on every OS. The consuming code is still gated by DEBUG
and WINDOWS, so on non-Windows the packages are restored but never compiled
in; the native asset only resolves for win-* RIDs.
The "Verify package contents" step (which checks the committed *.filelist
snapshots still match the built VSIX/MSI contents) had been excluding
packages.lock.json from its git diff to tolerate that per-OS churn. With the
locks now identical across OSes the carve-out is unnecessary, so it goes back
to a plain git diff --exit-code.
Assisted-by: Claude:claude-opus-4-8:Claude Code
ICSharpCode.Decompiler.Tests builds for the host RID (so the native
Microsoft.DiaSymReader.Native assets the Windows PDB tests need are copied),
which made its packages.lock.json host-specific (linux-x64 vs win-x64) and
drift between Linux and Windows restores. Add an explicit <RuntimeIdentifiers>
list next to the single <RuntimeIdentifier>: the lock then records every RID
host-independently while the build still targets the host RID. Apply the same
list to the TestRunner it pulls in.
TestRunner's lock is now fully portable. The test project's lock still carries
the OS-conditional DiaSymReader.Native difference in its base graph, which the
*.filelist-scoped "Verify package contents" step already tolerates.
Assisted-by: Claude:claude-opus-4-8:Claude Code
publish.ps1 now takes a -Configuration parameter (the workflow passes the
GNU-style --configuration <Debug|Release>, which pwsh binds to it) and uses
it for both the -c flag and the output paths. The win-x64 framework-dependent
bundle is produced for every configuration; the win-arm64 framework-dependent
and win-x64 self-contained bundles stay Release-only, matching what the zip
steps consume.
The build workflow publishes per-configuration before zipping, and the
framework-dependent binaries zip now reads straight from the publish output
(...\win-x64\publish\fwdependent) for the active configuration instead of
globbing the build output.
Assisted-by: Claude:claude-opus-4-8:Claude Code
Replace the Windows-only .bat helpers (clean / debugbuild / releasebuild /
restore / updatedeps and BuildTools/format) with cross-platform pwsh
scripts at the repo root: restore.ps1, build.ps1 (-Configuration), clean.ps1,
updatedeps.ps1 and BuildTools/format.ps1, alongside the existing publish.ps1.
Enable a packages.lock.json for every project by hoisting
RestorePackagesWithLockFile into the root Directory.Build.props (the four
core libraries set it individually before) and commit the generated locks,
so restores are repeatable and CI can cache packages off them.
Cache the NuGet packages folder in the three setup-dotnet workflows
(build-ilspy, build-frontends, codeql-analysis), keyed on the lock files
per the setup-dotnet caching guidance.
Scope the Debug "Verify package contents" check to the *.filelist outputs
it actually generates. A project's packages.lock.json is keyed only by
(framework, RID), with no host-OS axis, so a lock produced on Linux
legitimately differs from one produced on Windows whenever an OS-conditional
PackageReference applies (Debug+Windows pulls Microsoft.DiaSymReader*). The
Windows restore then rewrites those locks; that churn must not fail a step
whose job is to police the VSIX/MSI file lists.
Also drop the dead ILSpy.BamlDecompiler publish line from
publishlocaldev.ps1, mirroring the earlier publish.ps1 fix.
Assisted-by: Claude:claude-opus-4-8:Claude Code
The Avalonia app targets net10.0, so dotnet build emits ILSpy/bin/<config>/net10.0/,
but the framework-dependent zip still globbed a net10.0-windows folder that does not
exist, so it captured nothing. Point that zip at net10.0. The self-contained and arm64
zips keep net10.0-windows because that is the explicit -o path publish.ps1 (and the
installer/VSIX) write the published output to.
Assisted-by: Claude:claude-opus-4-8:Claude Code
The Windows build workflow had several run steps on one very long line --
the framework-dependent 7z zip with six glob paths, the restore/build/test
invocations, and the nuget push calls -- which were hard to scan and review.
Reformat them: single-command steps use a YAML folded scalar (run: >) with
one argument group per line, and the long lines inside the nuget-push |
blocks use PowerShell backtick continuation. The folded scalars rejoin to
byte-identical command strings, so runtime behavior is unchanged. No step
ordering, conditions, or the net10.0-windows publish paths are touched.
Assisted-by: Claude:claude-opus-4-8:Claude Code
* .NET 11 RC2 minimal changes
* Heuristic for transport feed Roslyn selection
* Microsoft.CodeAnalysis.NetAnalyzers from main NuGet feed
* Use the VS2026 image
* Switch all test projects to net11
* Extract constants
* Include vsix with plain nuget.config files
Christoph Wille
Siegfried Pammer
dependabot[bot]
ds5678