mirror of
https://github.com/icsharpcode/ILSpy.git
synced 2026-10-12 02:15:58 +00:00
Siegfried Pammer
cd10506c96
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