-
Notifications
You must be signed in to change notification settings - Fork 543
[tools] Don't detect/resolve binding resource packages in mtouch/mmp/dotnet-linker. Fixes #19378. #19407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[tools] Don't detect/resolve binding resource packages in mtouch/mmp/dotnet-linker. Fixes #19378. #19407
Conversation
…dotnet-linker. Fixes dotnet#19378. We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see dotnet#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. Fixes dotnet#19378.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
…ore launching mtouch.
…ereference-resolution
📚 [PR Build] Artifacts 📚Packages generatedView packagesPipeline on Agent |
💻 [CI Build] Windows Integration Tests passed 💻✅ All Windows Integration Tests passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) passed 💻✅ All tests on macOS M1 - Mac Big Sur (11.5) passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Ventura (13.0) passed 💻✅ All tests on macOS M1 - Mac Ventura (13.0) passed. Pipeline on Agent |
✅ API diff for current PR / commitLegacy Xamarin (No breaking changes)
NET (empty diffs)
✅ API diff vs stableLegacy Xamarin (No breaking changes).NET (No breaking changes)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 235 tests passed 🎉 Tests counts✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
/sudo backport release/8.0.1xx |
Backport Job to branch release/8.0.1xx Created! The magic is happening here |
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=8692642 for more details. |
…ges in mtouch/mmp/dotnet-linker. Fixes dotnet#19378. (dotnet#19463) We currently detect/resolve binding resource packages (the sidecar) in two places: * The ResolveNativeReferences MSBuild task. * Inside mtouch/mmp/dotnet-linker. Which means we end up passing every native library or framework twice to the native linker. This is usually not a problem, the native linker will ignore duplicated arguments, except when building remotely from Windows, in which case the build process may end up with native libraries in different locations, because files may end up in multiple places on the remote Mac if using absolute paths (see dotnet#18997 for a thorough explanation). So completely remove the logic to detect/resolve binding resource packages in mtouch/mmp/dotnet-linker, which will avoid the issue completely. A few mtouch tests also needed updating, since they're calling mtouch directly instead of going through the msbuild targets. Fixes dotnet#19378. Backport of dotnet#19407 --------- Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
We currently detect/resolve binding resource packages (the sidecar) in two places:
Which means we end up passing every native library or framework twice to the native linker.
This is usually not a problem, the native linker will ignore duplicated
arguments, except when building remotely from Windows, in which case the build
process may end up with native libraries in different locations, because files
may end up in multiple places on the remote Mac if using absolute paths (see
#18997 for a thorough explanation).
So completely remove the logic to detect/resolve binding resource packages in
mtouch/mmp/dotnet-linker, which will avoid the issue completely.
A few mtouch tests also needed updating, since they're calling mtouch directly instead
of going through the msbuild targets.
Fixes #19378.