ICSharpCode.Decompiler.Generators pins a stable Microsoft.CodeAnalysis.CSharp
(a source generator must not reference a Roslyn newer than the host compiler)
and ILSpy.AddIn.VS2022 pins a stable 4.0.1. Stable Roslyn lives only on
nuget.org, but the repo-root NuGet.config mapped Microsoft.CodeAnalysis.*
exclusively to the dotnet-tools feed, which carries only prerelease builds.
Both projects worked around that with a per-project NuGet.config. dotnet
restore honors it, since settings are computed per project directory, but
Visual Studio starts NuGet.config discovery at the solution directory and
never sees it: the first restore in VS on a machine with a cold NuGet cache
fails with NU1103 exactly as reported. Once any successful restore has put
the stable package into the global packages folder, source mapping is
satisfied from the cache and the problem never reappears on that machine,
which is why #3835 was closed as unreproducible.
NuGet consults every source that declares the longest pattern matching a
package id, so mapping Microsoft.CodeAnalysis.* to nuget.org as well as to
dotnet-tools makes both feeds available for the whole family: the stable
versions resolve from nuget.org and the prerelease $(RoslynVersion) from
dotnet-tools. Both per-project configs are then redundant and removed.
Verified with an empty NUGET_PACKAGES and the root config forced as the only
config (simulating VS's discovery): the old config reproduces the reported
NU1103; with the new config the generator, the decompiler tests (prerelease
Roslyn) and the VS add-in (stable 4.0.1 with its Workspaces dependencies)
all restore; restore.ps1 over ILSpy.sln leaves the lock files unchanged.
Assisted-by: Claude:claude-fable-5:Claude Code
The Avalonia port dropped ILSpy's single-instance feature, leaving three
inert surfaces behind: the --newinstance / --noactivate switches, and the
"Allow multiple instances" option were parsed and persisted but never read,
and every launch started a new process.
The former WPF implementation also encoded the executable location in the
mutex name, so two ILSpy builds at different paths never shared an instance.
That broke the Windows "Open with ILSpy" shell command: it launches a fixed
executable and would not reuse a running instance started from elsewhere.
Reimplement it with portable primitives (named Mutex + named pipes, no
P/Invoke): the first launch for a user takes the mutex and listens; a later
launch forwards its arguments over the pipe and exits. The namespace is
derived from machine + user only -- never the location -- so any launcher
reuses the running instance. --instanceid is a runtime reuse filter matched
against the running instance's actual executable identity (via
Environment.ProcessPath, single-file-bundle safe), not part of the mutex
name, so it never re-introduces the location partitioning it replaces. The
VS add-in passes its bundled exe path as --instanceid to prefer its own
build while still sharing with a plain launch of that same executable.
Assisted-by: Claude:claude-opus-4-8:Claude Code
Backfills the standard MIT X11 header on hand-written files that never
got one, attributing each to its first-commit author and year from git
history. Code vendored from dotnet/runtime and Humanizr/Humanizer gets
its origin's license lines and a provenance note instead. Generated
files (Resources.Designer.cs, the version-info template), tool-managed
suppression files, and BAML test-case fixtures intentionally stay
header-less.
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
ILSpy targets net10.0, not net10.0-windows; the VS add-in build paths, the
installer output dir, the local-dev publish script, and the VS Code launch
config still referenced the old net10.0-windows layout. Align them with the
actual TFM, matching publish.ps1 and the build workflow.
Assisted-by: Claude:claude-opus-4-8:Claude Code
A clean build currently has zero warnings; enforce that so new ones can't
accumulate unnoticed. Set TreatWarningsAsErrors in the root
Directory.Build.props rather than per project. ICSharpCode.ILSpyCmd keeps
its existing TreatWarningsAsErrors=false (project-level wins over the
imported default), and the three legacy net472 projects (the VS add-ins
and the installer builder) opt out explicitly since they only build on
Windows and aren't covered by the cross-platform CI that gates this.
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
* .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
* Use releaseTag with fallback to downloadUrl in updates.xml
* Add tests
* Prevent arbitrary downloadUrl - must start with BaseUrl as well
* Remove custom domain ilspy.net in end-user visible places
* Basics of net8.0. Breaking unit tests expected.
* Missed that TestRunner project was already upgraded to net7.0 (search and replace fail)
* Use Preview 6 locally
* Use .NET 8.0 RTM
* Final fixups
---------
Co-authored-by: Christoph Wille <[email protected]>
Siegfried Pammer