Closed sbomer closed 18 hours ago
I would be nice to have a test for this, but I do not have a good suggestion for where to add it.
Yeah, I don't have one either. Maybe if we created an assembly named system.diagnostics.diagnosticsource in a test and gave it version 100.0.0, it could work? Not sure.
even corelib would be CoreCLR's
Should we fails with a good error message for attempt to override CoreLib? I am sure that it is going to save some troubleshooting in future.
I hope this error message is good enough. It could be a little confusing because the intention of an old ILC reference is to override with an older version of SPC, but the message will suggest they tried to use a newer version. I hope putting the file paths in the message makes it clear.
Not sure we have a good place to test changes to the ILC build integration right now. The SDK has tests for the linker build integration even though the MSBuild logic now lives in runtime. We could do the same for ILC, but I'm not convinced it's worth it for this change - though I would definitely add tests when fixing https://github.com/dotnet/runtime/issues/108909.
/backport to release/9.0-staging
/backport to release/8.0-staging
Started backporting to release/9.0-staging: https://github.com/dotnet/runtime/actions/runs/11959116638
Started backporting to release/8.0-staging: https://github.com/dotnet/runtime/actions/runs/11959118198
Hi all. Happy to see this is resolved. How do we go about applying this fix, is it a case of waiting for a fix version of the SDK to be released?
Fixes https://github.com/dotnet/runtime/issues/109872, taking the approach @jkotas suggested in https://github.com/dotnet/runtime/issues/108909#issuecomment-2484728684.
Tested locally with the repro from https://github.com/dotnet/runtime/issues/109872, using
IlcBuildTasksPath
to point to a local build of the task.