🤖 Merge 'main' => 'xcode27.0'#25916
Conversation
#25884) The .NET standalone project templates (iOS, macOS, Mac Catalyst, tvOS) don't declare a `Framework` parameter in their `template.json` files. This means Visual Studio doesn't show the "Additional Information" page when creating a new project from these templates -- unlike MAUI templates which do have this parameter. This PR adds a `Framework` choice parameter to all 24 project-type template.json files. The parameter has a single choice matching the current TFM for the template pack (e.g. `net10.0-ios`), with a `replaces` directive that substitutes into the `<TargetFramework>` element in the generated `.csproj`. Affected templates: - iOS: app (C#, F#, VB), tabbed, lib, binding, notification extensions - macOS: app (C#, VB), lib, binding - Mac Catalyst: app (C#, VB), lib, binding - tvOS: app (C#, VB), lib, binding Fixes #17319 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
PR builds have been running on the ACES shared pool successfully. This switches the three CI entry pipelines to use ACES as well, so all builds run on the same pool infrastructure. Pipelines changed: - `build-pipeline.yml` - `run-ci-api-diff.yml` - `run-post-ci-build-tests.yml` Also updates the documentation comment in `templates/variables/common.yml` to reflect the current state (all pipelines now use ACES). 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
When the base hash in the API diff comparison requires a different Xcode version than the current hash, the comparison currently fails with an error and exits. This is unnecessarily strict on CI bots that often have multiple Xcode versions installed. This PR changes `tools/compare-commits.sh` to: - When `system-dependencies.sh` fails, extract the `XCODE_DEVELOPER_ROOT` from the base hash's `Make.config` and check if that Xcode is installed on the machine. - If it is, write a `configure.inc` pointing to it and retry -- the build then succeeds with the correct Xcode. - If the required Xcode is not installed (or the retry still fails for other reasons), emit a **warning** instead of an error and skip the API/generator comparison gracefully. This allows the API diff to work on CI when both Xcode versions are available, and avoids failing the entire job when they are not. 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Improve XML documentation for the `TWRequestMethod` enum: - Replace 'To be added.' placeholders with meaningful descriptions - Remove empty `<remarks>` node - Add proper documentation for `Get`, `Post`, and `Delete` values 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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
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.
…ixes #16860 (#25541) ## Summary When properties have generic delegate types (like `Action<NSObject?, NSError?>`), bgen now correctly propagates the `?` nullability annotations on the generic type arguments in the generated C# code. Previously, bgen only read the first byte of the `[NullableAttribute(byte[])]` array (for the outer type's nullability), ignoring the remaining bytes that encode nullability for generic type arguments. This caused properties like `Action<UIViewController?, NSError?>` to be rendered as `Action<UIViewController, NSError>` — losing the nullability annotations. Fixes #16860 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…immer to do. (#25909) Previously we always defaulted PublishTrimmed to true (except when building from Windows without a connection to a Mac), and disallowed setting it to false. Now default PublishTrimmed to false when all of the following are true: * No assemblies are being trimmed (TrimMode is 'copy'). * The link mode is 'None'. * Both PrepareAssemblies and PostProcessAssemblies are 'true'. When both PrepareAssemblies and PostProcessAssemblies are true, all the custom trimmer steps are moved to the assembly-preparer's post-processing step instead of running inside the trimmer. Combined with a link mode of 'None' (nothing is trimmed), there's nothing left for the trimmer (ILLink) to do, so we can skip it entirely. Skipping the trimmer meant the AOT dedup assembly (aot-instances.dll) was no longer created, because _CreateAOTDedupAssembly runs BeforeTargets=PrepareForILLink, and PrepareForILLink doesn't run when the trimmer is skipped. Fix this by making _AddDedupAssemblyToResolvedFileToPublish depend on _CreateAOTDedupAssembly, so the dedup assembly is created before the assemblies are post-processed regardless of whether the trimmer runs. Perf numbers are kind of all over the place, probably due to randomness on my machine, but this should eventually speed up the build once the PrepareAssembly task is optimized. Before: | Project | Runtime identifier | Link mode | PrepareAssemblies=false | PrepareAssemblies=true | Difference | | -------------- | ------------------ | --------- | ----------------------- | ---------------------- | ----------- | | monotouch-test | ios-arm64 | None | 00:02:05.46 | 00:02:09.64 | 00:00:04.18 | | monotouch-test | iossimulator-arm64 | None | 00:01:34.26 | 00:01:38.97 | 00:00:04.70 | | MySimpleApp | ios-arm64 | None | 00:01:20.30 | 00:01:23.26 | 00:00:02.96 | | MySimpleApp | iossimulator-arm64 | None | 00:00:53.64 | 00:00:55.38 | 00:00:01.74 | After: | Project | Runtime identifier | Link mode | PrepareAssemblies=false | PrepareAssemblies=true | Difference | | -------------- | ------------------ | --------- | ----------------------- | ---------------------- | ----------- | | monotouch-test | ios-arm64 | None | 00:02:06.53 | 00:02:12.52 | 00:00:05.99 | | monotouch-test | iossimulator-arm64 | None | 00:01:36.81 | 00:01:36.34 | 00:00:00.46 | | MySimpleApp | ios-arm64 | None | 00:01:14.63 | 00:01:19.11 | 00:00:04.48 | | MySimpleApp | iossimulator-arm64 | None | 00:00:54.26 | 00:00:53.07 | 00:00:01.19 | Also change the TimeSpan formatting in the performance report to print 2 fractional-second digits instead of 7. Even 2 is way too much precision, but it looks nicely symmetrical with the other double-digit numerical values. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
#25914) 'dotnet watch' builds the 'Compile' target directly (it runs 'dotnet build /t:Compile'). For binding projects this failed, because the binding-project override of CompileDependsOn prepends _GenerateBindings (which in turn runs _CompileApiDefinitions) before $(CompileDependsOn) - and $(CompileDependsOn) is where the default ResolveReferences lives. During a normal build ResolveReferences runs earlier as part of CoreBuild, so @(ReferencePath) is already populated when the binding targets run. But when the Compile target is built directly, nothing runs ResolveReferences first, so _CompileApiDefinitions compiles the API definitions with no references at all and fails with thousands of errors ("Predefined type 'System.Void' is not defined", missing System.Runtime, NSObject, ExportAttribute, etc.). Fix this by adding ResolveReferences to the front of the binding-project CompileDependsOn override, so references are always resolved before the binding-generation targets that need them. Also add a unit test (BuildBindingsTestWithCompileTarget) that builds a binding project with '/t:Compile'. Contributes towards https://devdiv.visualstudio.com/DevDiv/_workitems/edit/3024114. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This comment has been minimized.
This comment has been minimized.
…ject's location. Fixes 23898. (#25713) Always compute the LogicalName for Content and BundleResource items relative to the project file (`LocalMSBuildProjectFullPath`) instead of the defining project file (`LocalDefiningProjectFullPath`). This fixes the issue where SDKs (like the Razor SDK) that add Content items from a directory far from the project would produce nonsensical paths like `'../../../../../src/MyProject/file.png'` that get rejected. Fixes #23898 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Rolf Bjarne Kvinge <rokvin@microsoft.com>
) The template engine's `replaces` field and the `<TargetFramework>` in project files now use the fixed placeholder `DOTNET_TFM` instead of a literal TFM like `net10.0-ios`. This means those values no longer need manual updates when bumping to a new .NET version. A new script (`dotnet/update-tfm-in-templates.sh`) handles the remaining version-specific values (choices, defaultValue, descriptions in template.json and localize files). It reads `DOTNET_TFM` from `Make.config` and computes whether to include the previous TFM as an option based on the support policy: the previous TFM is offered until May 15th of the year after the current major .NET version was released. The script: - Preserves file formatting (BOM, indentation, trailing newlines) - Is idempotent (safe to run repeatedly) - Requires only bash 3.2+ and python3 🤖 Pull request created by Copilot --------- Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
|
Commit pushed:
|
This comment has been minimized.
This comment has been minimized.
✅ [PR Build #526e58f] Build passed (Build packages) ✅Pipeline on Agent |
✅ [PR Build #526e58f] Build passed (Detect API changes) ✅Pipeline on Agent |
✅ 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 |
✅ [PR Build #526e58f] Build passed (Build macOS tests) ✅Pipeline on Agent |
🔥 [CI Build #526e58f] Test results 🔥Test results❌ Tests failed on VSTS: test results 1 tests crashed, 4 tests failed, 174 tests passed. Failures❌ dotnettests tests (iOS)1 tests failed, 0 tests passed.Failed tests
Html Report (VSDrops) Download ❌ dotnettests tests (MacCatalyst)1 tests failed, 0 tests passed.Failed tests
Html Report (VSDrops) Download ❌ dotnettests tests (macOS)1 tests failed, 0 tests passed.Failed tests
Html Report (VSDrops) Download ❌ dotnettests tests (tvOS)1 tests failed, 0 tests passed.Failed tests
Html Report (VSDrops) Download ❌ monotouch tests (iOS)🔥 Failed catastrophically on VSTS: test results - monotouch_ios (no summary found). Html Report (VSDrops) Download Successes✅ 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 |
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.mdAutomated merge of
mainintoxcode27.0.Created by the code-radiator workflow.
Note: Template configuration conflicts were automatically resolved. Please review the changes to template.json files.