Repository navigation
🤖 Merge 'main' => 'xcode27.0' - #26093
Merged
rolfbjarne merged 17 commits intoJul 15, 2026
Merged
Conversation
This pull request updates the following dependencies ## From https://github.com/dotnet/dotnet - **Subscription**: [da09b56a-0fb1-439a-b894-def14d2ec0a4](https://maestro.dot.net/subscriptions?search=da09b56a-0fb1-439a-b894-def14d2ec0a4) - **Build**: [20260710.20](https://dev.azure.com/dnceng/internal/_build/results?buildId=3019962) ([322505](https://maestro.dot.net/channel/10307/github:dotnet:dotnet/build/322505)) - **Date Produced**: July 11, 2026 7:52:05 AM UTC - **Commit**: [d88a8f149a8b7a55a2ced403eb58128a0442d05e](dotnet/dotnet@d88a8f1) - **Branch**: [release/10.0.4xx](https://github.com/dotnet/dotnet/tree/release/10.0.4xx) - **Dependency Updates**: - From [10.0.0-beta.26359.109 to 10.0.0-beta.26360.120][2] - Microsoft.DotNet.Arcade.Sdk - Microsoft.DotNet.Build.Tasks.Feed - Microsoft.DotNet.SharedFramework.Sdk - From [10.0.400-preview.0.26359.109 to 10.0.400-preview.0.26360.120][2] - Microsoft.NET.Sdk - From [10.0.400-preview.26359.109 to 10.0.400-preview.26360.120][2] - Microsoft.TemplateEngine.Authoring.Tasks [2]: dotnet/dotnet@812e3e2...d88a8f1
This pull request updates the following dependencies ## From https://github.com/dotnet/xharness - **Subscription**: [02e03784-16b3-4ced-b02a-3715797fc7da](https://maestro.dot.net/subscriptions?search=02e03784-16b3-4ced-b02a-3715797fc7da) - **Build**: [20260710.1](https://dev.azure.com/dnceng/internal/_build/results?buildId=3019403) ([322405](https://maestro.dot.net/channel/2/github:dotnet:xharness/build/322405)) - **Date Produced**: July 10, 2026 3:45:06 PM UTC - **Commit**: [ab06ed6b9b6366d219751bdd80b04f8f37768bb3](dotnet/xharness@ab06ed6) - **Branch**: [main](https://github.com/dotnet/xharness/tree/main) - **Dependency Updates**: - From [11.0.0-prerelease.26357.1 to 11.0.0-prerelease.26360.1][1] - Microsoft.DotNet.XHarness.iOS.Shared [1]: dotnet/xharness@b631e17...ab06ed6
Device-specific builds were originally implemented to: 1. Build for a single architecture when we knew which device the app was going to be installed on. 2. Speed up resource compilation a bit by filtering resource compilation to the target device. However, the first reason is no longer applicable (arm64 is the only architecture), and the feature adds complexity and increases path lengths in the bin directory (which causes MAX_PATH issues on Windows). Changes: - Default `DeviceSpecificBuild` to `false` (was tied to `_BundlerDebug`). - Don't run ParseDeviceSpecificBuildInformation on .NET 11+, unless the private `_DeviceSpecificBuildOverride` property is set to true. This completely disables device-specific builds (unless the override is specified, which will hopefully never be necessary, and then we can remove the code in .NET 12). Contributes towards #23846 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
…is skipped (#25999) When `PrepareAssemblies` + `PostProcessAssemblies` are enabled and the trimmer is skipped (`_CanSkipTrimmer`), its output directory (`IntermediateLinkDir`) is empty, so `_ComputeTrimmedAssemblies` found no assemblies to scan. As a result `_CollectPostILTrimInformation` collected no inlined-dlfcn native symbols and no native code was generated for them, causing undefined native symbols (`_xamarin_Dlfcn_*_Native`) at link time. ## Fix - Collect the assemblies to scan from `@(ResolvedFileToPublish)` (the same source every other target uses) instead of the trimmer's output directory. This works whether or not the trimmer ran: when it's skipped the published assemblies are the final ones, and when it did run they're derived from the trimmed output, so the surviving symbol set is identical (verified against a normal trimmed build). - Harden `CollectPostILTrimInformation` to skip files that aren't managed assemblies, since `@(ResolvedFileToPublish)` can contain native libraries with a managed extension (e.g. a native `NativeLibrary.dll`), which make Cecil throw `BadImageFormatException`. ## Test Add a `dontlink|prepare-assemblies|inline-dlfcn-methods-compat` variation for monotouch-test that reproduces the issue. This only needs explicit coverage on .NET 10: there iOS defaults to MonoVM, which links the SDK by default, so the trimmer isn't skipped unless linking is explicitly disabled and `InlineDlfcnMethods` is enabled. On .NET 11+ iOS defaults to CoreCLR (which doesn't link) and `InlineDlfcnMethods` is enabled by default, so the plain `prepare-assemblies` variation already covers it — the new variation is therefore ignored on .NET 11+. A reusable `dontlink` test variation is also added. 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…25975) `GetAvailableDevices.RunSimCtlAsync()` used the **device type's** `MinRuntimeVersionString` (e.g. `"26.0.0"`) as the simulator's OS version when filtering against the app's `MinimumOSVersion`. This is wrong — it should use the **actual runtime version** from `simctl` (e.g. `"26.5"`). The device type's `minRuntimeVersionString` represents the minimum OS version the physical device hardware supports, not the actual OS version running on the simulator. For example, an iPhone 17 Pro device type has `minRuntimeVersionString: "26.0.0"`, but when created with the iOS 26.5 simulator runtime, its actual OS version is **26.5**. This causes `dotnet run --device` to reject every simulator device when the SDK version exceeds all device type `minRuntimeVersionString` values — for example in Xcode 26.5 (iOS 26.5 SDK) where every device type has `minRuntimeVersionString <= 26.3`. ## The fix Use the actual `simctl` runtime version, matching how `RunDeviceCtlAsync()` already handles physical devices: ```cs Version.TryParse (device.OSVersion, out var minimumOSVersion); ``` ## Removing `maximumOSVersion` `maximumOSVersion` was always set to the sentinel maximum value (`65535.255.255`) in both the simulator and physical-device code paths — `simctl` itself reports `maxRuntimeVersionString` as `65535.255.255` for every device type. As a result the max-version comparison in the filtering logic could never discard a device. This PR removes the now-redundant `DeviceInfo.MaximumOSVersion` property, the constructor parameter, the local variables, and the dead filter loop. ## Note This is partially a re-creation of #25931 (from @Happypig375). We have to re-create it because #25931 is from a fork, and our CI can't build from forks. 🤖 Pull request created by Copilot --------- Co-authored-by: Hadrian Tang <hadrianwttang@outlook.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ET 12 (#25962) Setting `NoBindingEmbedding=false` (embedding native libraries in the managed assembly) should no longer be necessary (and doesn't even work with `.xcframework`s, only `.framework`s, `.a` and `.dylib` files). However, supporting it duplicates the testing matrix for binding projects, and it's also a source of bugs, so start the process of removing support for it. Setting `NoBindingEmbedding=false` will now be deprecated in .NET 10+ with a build warning, and produces a build error in .NET 12+. And then at some point after .NET 12+ we can remove any supporting code/tests. --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> Co-authored-by: Rolf Bjarne Kvinge <rokvin@microsoft.com>
Fixes #25952. (#25970) A Release build of an app that references a binding project with an embedded dynamic framework failed with: strip: error: symbols referenced by indirect symbol table entries that can't be stripped in: .../CameraFramework.framework/CameraFramework The SymbolStrip task only passes '-S -x' to strip (to strip just debug/local symbols) when an item's 'Kind' metadata is 'Framework'/'Dynamic' (or the path ends in '.dylib'); otherwise it does a full strip, which fails for a dynamic library that references undefined symbols (objc_msgSend, ...) via the indirect symbol table. This regressed in commit 6b9cfc9 ("[msbuild] Filter static frameworks from post-processing items. Fixes #24840.", #24845), which changed the framework post-processing item in Xamarin.Shared.targets from: <_PostProcessingItem Include="@(_ResolvedNativeReference->'...')" Condition="'%(Kind)' == 'Framework'"> to: <_PostProcessingItem Include="@(_FilteredFrameworkToPublish->'...')"> `@(_ResolvedNativeReference)` carried the `Kind=Framework` metadata (as the removed condition shows), but `@(_FilteredFrameworkToPublish)` does not, so the metadata was silently lost. Frameworks embedded in a binding project are extracted by the linker without 'Kind' metadata, so they reached the SymbolStrip task with an empty 'Kind' and got a full strip. Apps that use a direct `<NativeReference Kind="Framework">` are not affected (the Kind flows through); only binding-embedded frameworks are. Fix this in two places: * Set `Kind=Framework` on the framework _PostProcessingItem (the block only ever contains frameworks), restoring the metadata the SymbolStrip task relies on. * Also detect frameworks by path in the SymbolStrip task (an item inside a '.framework' directory), mirroring the existing '.dylib' fallback, so a full strip is never done on a framework even if the 'Kind' metadata is missing. Also add a test (StripEmbeddedDynamicFramework) that builds an app which references a binding project that embeds a dynamic framework (NoBindingEmbedding=false) with symbol stripping enabled, and asserts the build succeeds. Without the fix this fails at the strip step. The test builds in Release (so the linker extracts the framework into the post-processing path), with a single RuntimeIdentifier (frameworks aren't post-processed in multi-RID builds) and NoSymbolStrip=false (so the framework is stripped even for the simulator). The existing binding projects that embed a framework only embed static libraries (as frameworks), which are filtered out and never copied to the app (so never stripped). The one project that embeds a dynamic framework (EmbeddedFrameworkInBindingProjectApp, which embeds XTest.framework) didn't hit the problem, because XTest.framework (built from libframework.m) doesn't call any external functions and so can be fully stripped. Make libframework.m send an Objective-C message so the framework binary imports an Objective-C runtime function referenced via the indirect symbol table; such a binary can't be fully stripped, so the test now exercises the strip code path. Fixes #25952 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…#26004) Image assets (and other compiled resources) coming from referenced libraries were lost on incremental builds. When a library is referenced, its embedded resources are extracted by the `_UnpackLibraryResources` target into typed item groups (`ImageAsset`, `AtlasTexture`, `InterfaceDefinition`, `Collada`, `CoreMLModel`, `SceneKitAsset`). That target is incremental (keyed on the referenced assemblies), so on a rebuild where the library is unchanged it's skipped and those item groups end up empty. For most resource types this is harmless because the resulting files are copied individually and persist in the app bundle. But image assets from all projects are compiled together into a single `Assets.car` by `actool`. When an app-owned asset changes, `actool` re-runs and regenerates `Assets.car` from the (now empty of library assets) `ImageAsset` group, dropping every image asset that came from a referenced library. Fix this the same way the partial app manifests are already handled: route the unpacked typed resources to private item groups, cache them to disk, and restore them into the real item groups from a new always-run `_LoadUnpackedLibraryResources` target, so they're present even when `_UnpackLibraryResources` is skipped. Also add a regression test that builds an app referencing a library with image assets, touches an app-owned asset to force `actool` to re-run, and verifies the library's asset is still present in `Assets.car`. Fixes #5755 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…types (#26059) Improve XML documentation for 20 types (mostly removing empty `<remarks>` nodes): - **EKParticipantScheduleStatus**: Improve enum member descriptions - **EKReminderPriority**: Improve enum member descriptions - **CFHTTPMessage**: Remove empty `<remarks>` node - **CFHTTPMessage.AuthenticationScheme**: Remove empty `<remarks>` node - **AVAudioPlayer**: Remove empty `<remarks>` node - **AVAudioSessionPortDescription**: Remove empty `<remarks>` node - **AVMetadataMachineReadableCodeObject**: Remove empty `<remarks>` node - **CXProvider**: Remove empty `<remarks>` node - **CPNavigationAlert**: Remove empty `<remarks>` node - **CLSContext**: Remove empty `<remarks>` node - **NSPersistentStoreCoordinator**: Remove empty `<remarks>` node - **NSDateComponents**: Remove empty `<remarks>` node - **NSUrlRequest**: Fix summary grammar - **HKSampleQuery**: Remove empty `<remarks>` node - **HKUnit**: Remove empty `<remarks>` node - **PHLivePhoto**: Remove empty `<remarks>` node - **SCNAnimatable**: Remove empty `<remarks>` node - **NetworkReachability**: Remove empty `<remarks>` node - **UIBarButtonItem**: Remove empty `<remarks>` node - **UIDocumentBrowserViewController**: Remove empty `<remarks>` node Total: 45 changed lines (14 insertions, 31 deletions) 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
InlineDlfcnMethodsStep iterated every type and every method (and every instruction of every method with a body) in every assembly, looking for calls to ObjCRuntime.Dlfcn to inline. Two changes make this cheaper: * Skip whole assemblies that can't contain Dlfcn calls. Dlfcn lives in the product assembly, so an assembly that neither is nor references the product assembly (the BCL, most third-party code) can't call it. Check that (cheapest first: the assembly references, then whether it's the product assembly, then finally whether it references the Dlfcn type) once per assembly and skip the whole thing - types, methods and instructions - otherwise. * Check the declaring type's simulator availability once per type in ProcessType instead of once per method. It only depends on the type, so recomputing it for every method (each call scans the type's availability attributes) was wasteful. For monotouch-test's assemblies (MySimpleApp, ios simulator) this cut the time spent in InlineDlfcnMethodsStep roughly in half for link None (2.85s -> 1.65s, dominated by the un-skippable product assembly) and ~6x for SdkOnly (1.58s -> 0.27s). Verified with monotouch-test on iOS (0 failed) with the inline-dlfcn-methods-strict and inline-dlfcn-methods-compat variations (which exercise the actual inlining) as well as release|linksdk. Build performance on iOS (MonoVM): | Project | Runtime identifier | Link mode | PrepareAssemblies=false | PrepareAssemblies=true | Difference | | -------------- | ------------------ | --------- | ----------------------- | ---------------------- | ------------ | | monotouch-test | ios-arm64 | None | 00:02:19.76 | 00:02:13.53 | -00:00:06.23 | | monotouch-test | ios-arm64 | SdkOnly | 00:01:26.94 | 00:01:47.17 | 00:00:20.22 | | monotouch-test | iossimulator-arm64 | None | 00:01:45.58 | 00:01:43.90 | -00:00:01.68 | | monotouch-test | iossimulator-arm64 | SdkOnly | 00:01:18.42 | 00:01:23.84 | 00:00:05.42 | | MySimpleApp | ios-arm64 | None | 00:01:14.39 | 00:01:16.94 | 00:00:02.54 | | MySimpleApp | ios-arm64 | SdkOnly | 00:00:22.02 | 00:00:45.90 | 00:00:23.87 | | MySimpleApp | iossimulator-arm64 | None | 00:00:53.94 | 00:00:54.32 | 00:00:00.37 | | MySimpleApp | iossimulator-arm64 | SdkOnly | 00:00:19.17 | 00:00:25.65 | 00:00:06.47 | Build performance on macOS (CoreCLR): | Project | Runtime identifier | Link mode | PrepareAssemblies=false | PrepareAssemblies=true | Difference | | -------------- | ------------------ | --------- | ----------------------- | ---------------------- | ------------ | | monotouch-test | osx-arm64 | None | 00:00:56.09 | 00:00:51.21 | -00:00:04.87 | | monotouch-test | osx-arm64 | SdkOnly | 00:00:53.56 | 00:00:52.37 | -00:00:01.18 | | MySimpleApp | osx-arm64 | None | 00:00:09.83 | 00:00:09.50 | -00:00:00.33 | | MySimpleApp | osx-arm64 | SdkOnly | 00:00:09.44 | 00:00:08.84 | -00:00:00.60 | --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…0 only. Fixes #25276 (#26018) The workaround for dotnet/runtime#127004 (adding the proxy type's attribute to the source type so ILLink's TypeMapHandler keeps the TypeMapAssociation) is no longer needed once the ILLink fix is available. The fix is only present in .NET 11+, so keep the workaround for .NET 10 and only stop applying it for .NET 11+: * In `TrimmableRegistrarStep`, only add the proxy attribute to the source type when targeting .NET 10 or earlier. * In `TypeMaps` (runtime), only read the workaround attribute from the source type for .NET 10 or earlier (gated with `!NET11_0_OR_GREATER`). A separate validation-only PR targeting `net11.0` (#26019) confirms everything still pass on .NET 11 with the workaround disabled (except the AppSizeTest test failed because NativeAOT app sizes went down ("App size changed significantly (-16,413 bytes)") - which is both expected and desirable). Fixes #25276 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
… can't). (#26064) The `/apply-gist` workflow read the gist via the GitHub REST Gists API using the default `GITHUB_TOKEN`, which is a GitHub App installation token. That token can't access the Gists API at all, so the "Validate gist owner" step failed with `403 Resource not accessible by integration` and the workflow never applied the files. Secret gists are readable by anyone who knows the id without authentication, so this fetches the gist metadata unauthenticated (a plain `fetch`/`curl` against `api.github.com`) in both the owner-validation and download steps. This keeps the approved-owner security check intact and needs no additional secrets. Note: `issue_comment` workflows always run from the default branch, so `/apply-gist` only picks up this fix once it's merged to `main`. 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Improve XML documentation for 13 types (removing empty nodes, fixing summaries): - **UIImage**: Remove empty `<remarks>` node - **UIView**: Fix summary - **VTCompressionSession**: Remove empty `<remarks>` node - **VTDecompressionSession**: Fix summary - **VNRequest**: Fix summary - **SecPolicy**: Remove empty `<remarks>` node, fix summary - **RPBroadcastConfiguration**: Remove empty nodes - **HMActionSet**: Remove empty nodes - **CALayer**: Remove empty `<remarks>` node - **CIColor**: Remove empty nodes - **MLDictionaryFeatureProvider**: Remove empty nodes - **MLMultiArrayConstraint**: Remove empty nodes - **NSUndoManager**: Remove empty nodes Total: 43 changed lines (15 insertions, 28 deletions) 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This can be selected by doing this in the csproj: ```xml <TargetFramework>net10.0-ios27.0</TargetFramework> <NoWarn>$(NoWarn);XCODE_27_0_PREVIEW</NoWarn> ```
…26065) Parsing our makefiles spawned a large number of tiny `$(shell echo ... | tr ...)`-style subprocesses, purely to do string manipulation (mostly upper/lower-casing platform names and mangling framework names). Because a root build recursively re-parses Make.config in every sub-make, these add up quickly and make even a no-op `make` noticeably slow. Replace them with make built-ins: - tests/test-libraries/frameworks/Makefile: mangle framework names with `$(subst .,_,...)` instead of `$(shell echo ... | tr '.' '_')`. - Make.config: add `uppercase`/`lowercase` functions (a `$(subst)` chain, since GNU make has no toupper/tolower), and define `DOTNET_PLATFORMS_UPPERCASE` / `DOTNET_PLATFORMS_LOWERCASE` up front. - Replace the per-platform `$(shell echo $(platform) | tr ...)` case conversions throughout the makefiles (Make.config, mk/rules.mk, dotnet/, src/, msbuild/, runtime/, builds/, tests/...) with `$(call uppercase,...)` / `$(call lowercase,...)`, and use the `DOTNET_PLATFORMS_UPPERCASE` / `DOTNET_PLATFORMS_LOWERCASE` list variables where a whole upper/lower-cased platform list was being built by hand. - src/frameworks.sources: convert the framework-list case conversions to `$(call uppercase,...)` / `$(call lowercase,...)`. - Make DOTNET_MANIFEST_VERSION_BAND simply-expanded (`:=`) so its `$(shell)` runs once instead of on every reference. Everything is value-preserving: the fully expanded make variable database is unchanged apart from the new helper variables. Measurements of `make -n` from the repo root: The subprocess count is exact and reproducible; the wall-clock numbers are approximate 4-run averages taken back-to-back on a busy machine, so the absolute values are inflated but the before/after ratio holds: subprocesses spawned during parse: 2526 -> 600 (~4x fewer) wall clock (4-run avg, loaded host): ~35s -> ~9s (~4x faster) 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
github-actions
Bot
requested review from
dalexsoto,
mauroa and
rolfbjarne
as code owners
July 14, 2026 20:16
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
Contributor
Author
There was a problem hiding this comment.
Protected files were modified in this pull request and require manual scrutiny before merge.
Please verify that each protected-file change is intentional, policy-compliant, and safe:
- Protected files:
README.md,.agents/files/training-log-macios-binding-creator.md,.agents/skills/macios-binding-creator/SKILL.md,.agents/skills/macios-binding-creator/references/binding-patterns.md,.agents/skills/macios-binding-creator/references/test-workflow.md,.agents/training-logs/macios-binding-creator.md
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.
rolfbjarne
enabled auto-merge
July 15, 2026 10:21
rolfbjarne
approved these changes
Jul 15, 2026
Collaborator
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ 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.
Collaborator
🚀 [CI Build #1a9996f] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 195 tests passed 🎉 Tests counts✅ assembly-processing: All 1 tests passed. Html Report (VSDrops) Download macOS tests✅ Tests on macOS Sonoma (14): All 5 tests passed. Html Report (VSDrops) Download Linux Build VerificationPipeline on Agent |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Caution
Protected files were modified in this change.
This pull request is in
request_reviewmode and requires explicit human scrutiny before merge.Protected files:
README.md,.agents/files/training-log-macios-binding-creator.md,.agents/skills/macios-binding-creator/SKILL.md,.agents/skills/macios-binding-creator/references/binding-patterns.md,.agents/skills/macios-binding-creator/references/test-workflow.md,.agents/training-logs/macios-binding-creator.mdAutomated merge of
mainintoxcode27.0.Created by the code-radiator workflow.