Fix net472 tool tests failing on System.Collections.Immutable bind - #732
Conversation
IKVM.Tools.Importer.Tests fails every row on net472 with Could not load file or assembly 'System.Collections.Immutable, Version=10.0.0.0' ---> ... 'Version=8.0.0.0' at IKVM.Tools.Importer.ImportOptions..ctor() The cause is in the SDK's .NET Framework test host rather than in anything we ship. testhost.net472.exe.config in 10.0.302 carries <bindingRedirect oldVersion="1.0.0.0-10.0.0.0" newVersion="10.0.0.0" /> for System.Collections.Immutable, and the host directory holds 10.0.0.0. So IKVM.CoreLib's 8.0.0.0 reference is redirected up to 10.0.0.0, the loader then finds the 8.0.0.0 copy sitting next to the tests, and the bind fails on major version. Bumping the two tool test projects puts 10.0.0.0 beside the tests, which is what the host's redirect points at. Deliberately not touching the pins in IKVM.deps.targets, IKVM.CoreLib, ikvmc, ikvmstub or the SDK targets. ikvmc ships as a standalone executable with its own config and never sees the test host's redirect, so this is a test environment problem and not a product one. The pins in IKVM.NET.Sdk.targets and IKVM.MSBuild/buildTransitive reach consumers, and changing those to satisfy a test host quirk would take on real risk for no gain. The tests now run against a different System.Collections.Immutable than production ships, which is a small loss of fidelity, but the alternative changes what users get. Not verified locally: the net472 build stops earlier on NETSDK1094 from ikvmstub wanting a runtime identifier for ReadyToRun, which is unrelated and already present. Restore is clean and net472 resolves to 10.0.10.
This reverts commit 168321f.
|
Reverted â the change does not work, and makes things worse. Leaving the PR open as a draft because the diagnosis in the description is still correct and worth keeping; only the fix was wrong. What CI showed
So it did not fix the target and it regressed Linux. Why bumping the test project could never have worked
<ProjectReference Include="...\IKVM.CoreLib\IKVM.CoreLib.csproj">
<PrivateAssets>all</PrivateAssets>
<OutputItemType>IkvmLibsItem</OutputItemType>
</ProjectReference>
What this means for the real fixThe assembly beside the tests is determined by That makes this a genuine trade-off rather than an oversight, and worth a decision rather than another guess:
The diagnosis of the mechanism stands: |
Second attempt at the net472 bind failure, taking the other route: leave the package versions alone and change the redirect instead. The .NET Framework test host carries its own redirect in testhost.net472.exe.config, <bindingRedirect oldVersion="1.0.0.0-10.0.0.0" newVersion="10.0.0.0" /> next to a 10.0.0.0 copy of the assembly. IKVM.CoreLib is built against 8.0.0.0, and the copy beside the tests comes from CoreLib's own output via IkvmLibsItem in IKVM.refs.targets, so it is 8.0.0.0 too. The host redirects the reference up to 10.0.0.0 and the bind fails on major version. AutoGenerateBindingRedirects only emits 0.0.0.0-8.0.0.0 for this assembly, because 8.0.0.0 is the highest anything resolves to, and that range does not cover what the host asks for. An explicit app.config widening it to 10.0.0.0 while keeping the target at 8.0.0.0 points the bind back at the assembly that is actually on disk. Whether this survives is the open question: VSTest merges the test source's config with the host's into a temp file, and it is not documented which side wins for a duplicate identity. The first attempt, bumping the test project's package reference, failed because the assembly beside the tests never came from that reference in the first place. CI is the check.
|
Second attempt pushed, taking the other route: leave package versions alone and change the redirect instead. What changedAn explicit <assemblyIdentity name="System.Collections.Immutable" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-10.0.0.0" newVersion="8.0.0.0" />Why this shape
Widening the range to 10.0.0.0 while keeping the target at 8.0.0.0 points the bind back at the assembly that is genuinely on disk. No package version moves, so nothing consumers receive is affected. What is genuinely uncertainVSTest merges the test source's config with the host's into a temp file (the Fusion log shows Note also that The first attempt failed because the assembly beside the tests never came from the test project's package reference. It arrives from |
|
This works. Marking ready. Result
The target job is fixed, and unlike the first attempt there is no regression on Linux. Why widening the range was the right leverThe host's redirect covers Declaring Remaining failures are not from this PR
Neither can be caused by this change, which adds a single Note for reviewersThe first attempt on this branch bumped the test project's |
1 participant
Fixes the
IKVM.Tools.Importer.Tests:net472:win-x64failure that has been red onmainsince at least July, and is one of the two deterministic failures blocking #727 and #730.Cause
Every row fails at:
The problem is in the SDK's .NET Framework test host, not in anything we ship.
testhost.net472.exe.configin SDK 10.0.302 contains:and the host directory ships
System.Collections.Immutable10.0.0.0.So
IKVM.CoreLibasks for 8.0.0.0, the host redirects that up to 10.0.0.0, the loader finds the 8.0.0.0 copy sitting beside the tests, and the bind fails on major version. That accounts for the otherwise baffling10.0.0.0â8.0.0.0pair in the exception.This was confirmed by turning on Fusion bind logging in CI (#728), which named
IKVM.CoreLibas the requester and showed the bind resolving against a VSTest-generated temp config rather than the test assembly's ownapp.configâ which is why the shipped redirect looked correct but was never the one applied.Fix
Bump
System.Collections.Immutable8.0.0 â 10.0.10 inIKVM.Tools.Importer.TestsandIKVM.Tools.Exporter.Tests, so the assembly beside the tests is the one the host's redirect points at.What is deliberately not changed
The pins in
IKVM.deps.targets,IKVM.CoreLib,ikvmc,ikvmstuband the SDK targets are left alone.ikvmcships as a standalone executable with its own config and never sees the test host's redirect, so this is a test environment problem rather than a product one. The pins inIKVM.NET.Sdk.targetsandIKVM.MSBuild/buildTransitive/reach consumers, and changing those to satisfy a test-host quirk would take on real risk for no gain.The trade-off is that these tests now run against a different
System.Collections.Immutablethan production ships. That is a small loss of fidelity, but the alternative changes what users get.Verification
Restore is clean â no
NU1605, which matters because it isWarningsAsErrorsin this repo â and net472 resolves toSystem.Collections.Immutable/10.0.10.Not verified by a local test run: the net472 build stops earlier on
NETSDK1094fromikvmstubwanting a runtime identifier for ReadyToRun. That is unrelated and already present onmain. CI is the check.Scope
This clears one of the two deterministic failures.
sun/security/ssl/X509KeyManager/PreferredKey.javaonOpenJDK.Testspartition 7 is separate and still open, so neither #727 nor #730 goes fully green on this alone.