[htsugawa]

Why

Master Build (dotnet_master.yml) has failed on every push to master since the lock files came in (#798). The failure happens at dotnet restore /property:Configuration="Release vendor unsupported", with 24 × NU1102 and one NU1004. The lock files pin RawDataHandler-Vendor-UnSupported to versions that are not in the sources CI uses:

• nuget.org has none;
• Assemblies/ holds only 1.3.9699.471.

Nothing has been built, tested or published from master since then.

PR Check is a different story: its red X on recent PRs comes from one GUI test. #833 fixes that test, and #833 should merge first.

What changes

1. Lock files (25 files). The 25 packages.lock.ReleaseVendorUnsupported.json files are regenerated against exactly the CI sources (nuget.org plus Assemblies/), with an isolated cache. The diff is limited to three things:

• 49 RawDataHandler-Vendor-UnSupported entries now resolve to 1.3.9699.471. Their content hash equals the SHA-512 of Assemblies/RawDataHandler-Vendor-UnSupported.1.3.9699.471.nupkg.
• Four transitive packages are added to five MSDIAL4 sections: Microsoft.Bcl.AsyncInterfaces 5.0.0, System.Memory 4.5.5, System.Numerics.Vectors 4.5.0 and ZstdSharp.Port 0.8.1.
• MsdialGuiApp gains win-x64 sections.

Directory.Build.props (locked mode), PackageReference ranges, Assemblies/ and all source files are unchanged.

2. Console publish legs. dotnet_master.yml restores and publishes the two console jobs with -p:RestoreLockedMode=false, because their --runtime publish needs RID sections that locked mode refuses (NU1004).

3. Optional, separate commit. dotnet_pr.yml gets a locked "Release vendor unsupported" restore before the Debug restore, so a PR that changes a PackageReference without regenerating the locks fails at PR time instead of on master. Drop this commit if you do not want it.

4. Optional, separate commit. dotnet_master.yml passes -p:ErrorOnDuplicatePublishOutputFiles=false to the MSDIAL5 GUI publish. The publish-msdial4 and publish-msdial5-console commands already pass it. Without it the job fails with NETSDK1152, because System.Data.SQLite.Core 1.0.112.2 ships two byte-identical SQLite.Interop.dll files.

Verified locally (Windows)

Locked restore. A locked "Release vendor unsupported" restore of a clean export, from an empty package cache, with only nuget.org and Assemblies/:

• 78/78 projects, 0 errors, 0 lock files written;
• the cache holds only RawDataHandler-Vendor-UnSupported 1.3.9699.471.

The same setup with master's lock files reproduces CI's 24 × NU1102 + NU1004.

Master Build test job. dotnet build --no-restore --no-incremental -c "Release vendor unsupported" gives 0 errors. dotnet test gives 15 assemblies, 2166 tests: 2149 passed, 17 skipped, 0 failed.

Two substitutions were needed on this machine:

• the .NET 4.8.1 reference assemblies came from the nuget.org package, standing in for windows-latest's installed pack;
• long paths had to be avoided.

PR Check order: the new locked restore followed by the Debug restore leaves no project in the locked Release state.

Not proven yet

• The four publish jobs, and the Linux/macOS legs, run for the first time on the push to master.
• Master artifacts will carry RawDataHandler 1.3.9699.471. Refreshing Assemblies/ with a newer RawDataHandler is a separate change.

For the reviewer (lock-file author)

Please confirm that pinning to the Assemblies/ package is the intended source of truth. The alternative is adding a newer nupkg to Assemblies/.

🤖 Generated with Claude Code