[automated] Merge branch 'net11.0' => 'release/11.0.1xx-preview7' - #36880
Closed
github-actions[bot] wants to merge 8 commits into
Closed
[automated] Merge branch 'net11.0' => 'release/11.0.1xx-preview7'#36880github-actions[bot] wants to merge 8 commits into
github-actions[bot] wants to merge 8 commits into
Conversation
<!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change On iOS 26, the picker dialog's action button label changed from **"Done"** to **"selected"**, which broke the `Issue34971` UI test that hard-coded the `"Done"` accessibility id when dismissing the `Picker` dialog. This PR updates the test to dynamically resolve the correct button label based on the iOS version under test, using the existing `HelperExtensions.IsIOS26OrHigher` helper. **Changes:** - Added a `doneButton` computed property in `Issue34971` that returns `"selected"` on iOS 26+ and `"Done"` otherwise (via `App is AppiumIOSApp iosApp && HelperExtensions.IsIOS26OrHigher(iosApp)`). - Updated `App.WaitForElement`/`App.Tap` calls in `CloseOpenedPicker` to use this computed value instead of the hard-coded `"Done"` string. **Issue Fixed** Fixes #36857
|
Azure Pipelines: Successfully started running 1 pipeline(s). There may be pipelines that require an authorized user to comment /azp run to run. |
> [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description XAML Incremental Hot Reload (XIHR) was enabled **by default for Debug builds** on the net11.0 branch, which is causing issues. This PR makes XIHR **opt-in** instead of on-by-default. ### Changes - `Microsoft.Maui.Controls.targets`: `EnableMauiIncrementalHotReload` now defaults to `false` unless the developer explicitly sets it to `true`. Removed the `Configuration == 'Debug'` branch that defaulted it to `true`. - Legacy XAML Hot Reload remains the default fallback (`MauiXamlHotReload` stays `Legacy` when XIHR is off). - Updated a stale comment in `MSBuildTests.cs` that described XIHR as "on by default in Debug". ### Notes - The runtime feature switch default (`IsIncrementalHotReloadEnabledByDefault`) is already `false`, so this change makes the MSBuild default coherent with the runtime default end-to-end. - To opt back in, set `<EnableMauiIncrementalHotReload>true</EnableMauiIncrementalHotReload>` in the project. - Existing XIHR unit tests set the flag explicitly and are unaffected. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 78048f76-1e94-4d6a-b306-7d8c74ddea9f
…enderer and Handler code paths (#36328) > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Summary Adds Android device test coverage for the Handler-based Shell, Modal, and Window implementations alongside the existing Renderer-based tests, allowing both Android implementations to run in CI. Also fixes a bottom navigation menu update issue in TabbedViewManager.cs that was uncovered while adding this coverage. ### Changes - Added RendererHandlerVariant.cs to define shared [Trait] constants (AndroidShellRenderer and AndroidShellHandler) for identifying Renderer and Handler test variants. - Updated xUnitCustomizations.cs to read the Variant trait (Android only) and prefix test display names with [Renderer] or [Handler], making it easy to identify the implementation that failed in CI. - Updated ShellTests, ModalTests, WindowTests, ShellFlyoutTests, ShellTabBarTests, and their Android/iOS partials to make the required setup methods virtual and tag the existing tests with the Renderer trait. This allows the same test implementations to be reused by the Handler subclasses instead of duplicating them. - Added ShellHandlerSubclasses.Android.cs, which contains ShellHandlerTests_Shell, ModalHandlerTests, and WindowHandlerTests. These subclasses reuse the existing test implementations while registering the Handler implementation on Android and are tagged with the Handler trait. ### Source Fix – TabbedViewManager.cs **Issue:** SetupBottomNavigationView() called menu.Clear() during tab updates, recreating IMenuItem instances. The Handler-based tests validate menu item identity, which caused the tests to fail. **Fix:** Updated the menu setup logic to use BottomNavigationViewUtils.SetupMenu(), which updates existing menu items instead of recreating them. ### Test Fix – PushingNavigationPageModallyWithShellShowsToolbarCorrectly **Issue:** The existing GetPlatformToolbar() helper supported ShellRenderer but not ShellHandler. In the Handler implementation, the toolbar is hosted within an outer CoordinatorLayout, so the existing lookup logic did not work. **Fix:** Added an IsBackButtonVisible helper and a GetShellHandlerToolbar() helper to locate the toolbar through the nested CoordinatorLayout hierarchy.
…apper (#34426) > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Root Cause The MAUI handler lifecycle calls `ConnectHandler` before the property mappers run. When a developer sets a custom `WebViewClient` in `ConnectHandler`, the subsequent execution of `MapWebViewClient` (triggered by the mapper pipeline) would call `platformView.SetWebViewClient(new MauiWebViewClient(...))`, silently discarding the custom client. Since `MapWebViewClient` and `MapWebChromeClient` serve no purpose beyond initial setup — they are not responding to any virtual view property change — registering them in the mapper was incorrect. Moving client creation to `CreatePlatformView()` and removing them from the mapper pipeline ensures the default clients are set once, before `ConnectHandler` runs, allowing developers to override them reliably. ### Description of Change On Android, `WebViewHandler` registered `MapWebViewClient` and `MapWebChromeClient` as property mapper entries. These mappers created new `MauiWebViewClient`/`MauiWebChromeClient` instances and set them on the platform view every time they ran — **after** `ConnectHandler` was called. This meant any custom `WebViewClient` set by users in `ConnectHandler` (e.g., to intercept navigation via `ShouldOverrideUrlLoading`) would be silently replaced by MAUI's default client. **Changes:** - Removed `MapWebViewClient` and `MapWebChromeClient` mapper methods entirely - Default clients are now created **once** in `CreatePlatformView()` and stored as private fields (`_webViewClient`, `_webChromeClient`) - `DisconnectHandler` uses the stored field references directly for `Disconnect()` and `Dispose()`, rather than casting from the platform view - Users can now safely override the `WebViewClient` in `ConnectHandler` without MAUI replacing it ### Issues Fixed Fixes #34392 --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
### Issue Details After merging regression PR #32905 – [XSG] Improve diagnostic reporting during binding compilation, XAML bindings that were previously ignored during source-generated binding compilation started failing the build. The issue was observed in bindings that used: AncestorType={x:Type ContentPage} The build now fails with MAUIG2045, which is treated as an Error. Previously, the source generator silently skipped unsupported or invalid bindings without reporting diagnostics, so these bindings did not block the build. ### Description of Change <!-- Enter description of the fix in this section --> PR #32905 updated the binding source generator to report diagnostics instead of silently ignoring invalid bindings. Previous behavior ``` // In CompiledBindingMarkup.cs return false; // TODO report diagnostic ``` Updated behavior ``` context.ReportDiagnostic( Diagnostic.Create(Descriptors.BindingPropertyNotFound, ...)); ``` The PR introduced six new MAUIG diagnostics that align with the older XamlC XC* diagnostics, improving diagnostic visibility during binding compilation. Because MAUIG2045 is emitted as an Error, bindings using AncestorType={x:Type ContentPage} now fail compilation. To resolve the issue, the bindings were updated to use the correct view type: AncestorType={x:Type views:BasePage} This change restores successful compilation while preserving the new diagnostic behavior introduced by PR #32905. ### Issues Fixed <!-- Please make sure that there is a bug logged for the issue being fixed. The bug should describe the problem and how to reproduce it. --> Fixes #36827
…errors in Essentials (refs #36451) (#36619) > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! Workflow artifact: ci-fix Artifact kind: help Refs: #36451 Target branch: net11.0 Attempt: 1/10 ## Attempt 1 of 10 Guard the version-specific iOS/Android APIs that CA1416 flags on the `net11.0-ios26.5` / `net11.0-android37.0` target frameworks so the Essentials assembly builds cleanly. ## Root cause Essentials calls several platform APIs that are unsupported (or only supported above the assembly's minimum) on the new `net11.0-ios26.5` / `net11.0-android37.0` TFMs, which the platform-compatibility analyzer reports as CA1416 build errors: - `src/Essentials/src/Map/Map.ios.watchos.macos.cs` — `MKPlacemark` (unsupported on iOS 26+). - `src/Essentials/src/MediaPicker/MediaPicker.ios.cs` — `PHPickerConfiguration` (iOS 14+) and the `UIGraphics.BeginImageContext*` family (unsupported on newer iOS). - `src/Essentials/src/Permissions/Permissions.ios.cs` — `UNAuthorizationStatus.Ephemeral` (iOS 14+) and `CNAuthorizationStatus.Limited` (iOS 18+). - `src/Essentials/src/MediaPicker/MediaPicker.android.cs` — MediaStore `IsPending`/`RelativePath` (API 29+) and `MediaStore.ExtraPickImagesMax` (API 33+). - `src/Essentials/src/Permissions/Permissions.android.cs` — `Manifest.Permission.Flashlight` (unsupported on Android 24+). ## Fix Minimal, behavior-preserving platform guards — no API surface change, no muted tests: - **Map (iOS 26+):** keep `MKPlacemark` + `MKMapItem.OpenMaps` and scope a `#pragma warning disable CA1416` to that call site. `MKPlacemark` is deprecated on iOS 26, not removed, so runtime behaviour — including `MapLaunchOptions.Name` and `NavigationMode` — is unchanged. Migrating to `MKMapItem(location:address:)` is tracked by #36845. - **MediaPicker.ios:** guard the second `PHPickerConfiguration` block with `OperatingSystem.IsIOSVersionAtLeast(14, 0)` (mirrors the already-guarded first block); replace `UIGraphics.BeginImageContextWithOptions`/`GetImageFromCurrentImageContext`/`EndImageContext` with `UIGraphicsImageRenderer` (iOS 10+), preserving opacity, scale, and draw rect. - **Permissions.ios:** guard `UNAuthorizationStatus.Ephemeral` behind `IsIOSVersionAtLeast(14)` and `CNAuthorizationStatus.Limited` behind `IsIOSVersionAtLeast(18)` (switch → guarded if/else so the guarded enum members are only referenced when supported). - **MediaPicker.android:** annotate `SaveToMediaStoreAsync` with `[SupportedOSPlatform("android29.0")]` (it is only reached from the API 29+ branch of `SaveToGalleryAsync`); guard `MediaStore.ExtraPickImagesMax` with `OperatingSystem.IsAndroidVersionAtLeast(33)`. - **Permissions.android:** build the Flashlight `RequiredPermissions` dynamically, always requesting `Camera` and only adding `Flashlight` when `!OperatingSystem.IsAndroidVersionAtLeast(24)`. ## What is unverified / where I need help - The `net11.0-ios26.5` / `net11.0-android37.0` builds cannot be compiled on the Linux CI-fixer runner, so this fix is **not runner-validated** — it needs the PR's own CI (`maui-pr`) to confirm CA1416 is cleared. A maintainer needs to `/azp run maui-pr`. - The issue reports ~28 CA1416 errors but only a subset are quoted; this change addresses every API enumerated in the issue's recommended action. If CI surfaces additional violations, a follow-up attempt on this same PR will cover them. - Map: an earlier revision of this PR rerouted coordinate opens through the `maps.apple.com` URL scheme. That was reverted — the URL form drops `MapLaunchOptions.Name` and ignores `NavigationMode` (`dirflg` is only honoured alongside a `daddr`), which would have been a silent regression on iOS 26+ and Mac Catalyst 26+. It is now a scoped CA1416 suppression with the migration tracked in #36845. ## Validation - Command: `not run because target frameworks net11.0-ios26.5 / net11.0-android37.0 cannot be built on the Linux runner` - Result: not run ## Evidence - Original failing build (from tracking issue): see #36451 > Generated by [CI Failure Fixer (net11.0)](https://github.com/dotnet/maui/actions/runs/29546079512) · 448.4 AIC · ⌖ 31.5 AIC · ⊞ 5.2K · [◷](https://github.com/search?q=repo%3Adotnet%2Fmaui+%22gh-aw-workflow-id%3A+ci-status-fix-net11%22&type=pullrequests) <!-- gh-aw-agentic-workflow: CI Failure Fixer (net11.0), engine: copilot, version: 1.0.63, model: claude-opus-4.8, id: 29546079512, workflow_id: ci-status-fix-net11, run: https://github.com/dotnet/maui/actions/runs/29546079512 --> <!-- gh-aw-workflow-id: ci-status-fix-net11 --> <!-- gh-aw-workflow-call-id: dotnet/maui/ci-status-fix-net11 --> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 76c88205-cf28-4deb-bc55-75e9c2363eb8 Co-authored-by: Jakub Florkowski <42434498+kubaflo@users.noreply.github.com>
<!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ## Summary Extracts both validated BL0016 sample fixes from dependency PR #36838 onto `net11.0`: - `src/BlazorWebView/samples/WebViewAppShared/ExampleJsInterop.cs` - `src/BlazorWebView/samples/MauiRazorClassLibrarySample/ExampleJsInterop.cs` The updated .NET 11 Preview 7 SDK flowing through #36838 enables BL0016 analysis for these JavaScript interop calls. This focused change prepares `net11.0` for that flowed SDK; it does not assert that the branch's older SDK currently fails these builds. ## Exception semantics Operational module import, prompt, and DOM update calls catch `JSException` and rethrow `InvalidOperationException` with operation-specific context. Module disposal catches only `JSDisconnectedException`, because a disconnected JavaScript context no longer requires disposal; other disposal failures continue to propagate. ## CI evidence - [maui-pr build 1528734](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1528734) surfaced BL0016 diagnostics in both `ExampleJsInterop` copies after the Preview 7 dependency update. - [maui-pr build 1529843](https://dev.azure.com/dnceng-public/public/_build/results?buildId=1529843), after the `WebViewAppShared` source fix, had no remaining diagnostics for that copy and still identified the Razor class library copy, motivating the second validated fix. ## Validation - `dotnet build src/BlazorWebView/samples/WebViewAppShared/WebViewAppShared.csproj -f net11.0 -c Debug` — passed, 0 warnings and 0 errors - `dotnet build src/BlazorWebView/samples/WebViewAppShared/WebViewAppShared.csproj -f net11.0 -c Release` — passed, 0 warnings and 0 errors - `dotnet build src/BlazorWebView/samples/MauiRazorClassLibrarySample/MauiRazorClassLibrarySample.csproj -f net11.0 -c Debug` — passed, 0 warnings and 0 errors - `dotnet build src/BlazorWebView/samples/MauiRazorClassLibrarySample/MauiRazorClassLibrarySample.csproj -f net11.0 -c Release` — passed, 0 warnings and 0 errors - Searched `src/BlazorWebView/samples/**`: exactly two `ExampleJsInterop` implementations and seven relevant `IJSRuntime`/`IJSObjectReference` invocation or disposal call sites; all operational calls are guarded and disconnection is ignored only during disposal. - `git diff --check` passed. Co-authored-by: PureWeen <223556219+Copilot@users.noreply.github.com> Copilot-Session: c6ae0385-a806-4d6c-9725-dc102062c5c4
Reset patterns: - global.json - NuGet.config - eng/Version.Details.xml - eng/Versions.props - eng/common/*
kubaflo
pushed a commit
that referenced
this pull request
Jul 31, 2026
<!-- Please let the below note in for people that find this PR --> > [!NOTE] > Are you waiting for the changes in this PR to be merged? > It would be very helpful if you could [test the resulting artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from this PR and let us know in a comment if this change resolves your issue. Thank you! ### Description of Change Auto-approve and enable GitHub native auto-merge for immutable snapshots of these exact forward-merge targets: ```text main => net11.0 net11.0 => release/11.0.1xx-preview7 net11.0 => release/11.0.1xx-rc1 net11.0 => release/11.0.1xx-rc2 ``` ### Immutable snapshot design Each caller workflow checks for its generated merge PR before invoking Arcade: ```text no open merge PR -> run Arcade and create a fresh snapshot open merge PR -> leave its branch unchanged while CI runs ``` The checks use exact head/base pairs and require the PR authoring App to be `github-actions` with `isCrossRepository == false`. The release workflow resolves the current `MergeToBranch` from `github-merge-flow-release-11.jsonc` on `net11.0`, and passes `configuration_file_branch: net11.0` to Arcade so the gate and merge implementation use the same source of truth. Workflow runs are serialized with distinct concurrency groups so simultaneous push/schedule/manual runs cannot both pass the check and create or update the same PR. Because scheduled workflows start from the default branch, the release schedule uses a schedule-only job to dispatch `merge-net11-to-release.yml` at ref `net11.0`; the dispatched run is not a schedule event and cannot recurse. During rollout, the schedule job first compares the parsed safety-critical sections (`concurrency`, `CheckForOpenMergePullRequest`, and `Merge`) between the workflow on `main` and `net11.0`. It skips the dispatch until the full immutable-snapshot gate has propagated, while allowing unrelated branch-specific workflow differences. Fetch or parse failures fail visibly instead of dispatching an unknown definition. The read-only snapshot checks use read-only `GITHUB_TOKEN` permissions. Only the reusable Arcade merge job retains content and pull-request write access. New source commits that arrive while a merge PR is open wait for the next generated PR. Once the current PR merges or closes, the next push or daily schedule creates a fresh snapshot containing the remaining commits. This intentionally stops using Arcade's existing "fast-forward the open merge PR" behavior. The generated PR head does not change during CI, so source-branch pushes do not invalidate its approval or restart CI. ### Policy Service rule The rule runs only on `Opened`; `Synchronize` is not accepted. It requires: - event sender `github-actions[bot]` - event sender is also the PR author - exact target branch - exact, fully anchored generated title Human conflict-resolution pushes do not trigger reapproval. Bot-attributed `/rebase` synchronization also does not trigger the policy, closing the review-bypass path identified in the adversarial review. ### Review behavior and accepted limitation `MAUI protection` intentionally remains: ```text dismiss_stale_reviews_on_push: true require_last_push_approval: false required_approving_review_count: 1 ``` This preserves the repository's human-review workflow: a maintainer who pushes a fix to another person's PR can provide the subsequent approval without requiring a third reviewer. This PR does not modify repository rulesets or add a bypass. The generated merge PR remains safe under these settings. Policy Service approves only the initial `Opened` snapshot, the caller workflow refuses to invoke Arcade while the exact bot-authored PR remains open, and any out-of-band head push dismisses the approval with no automatic reapproval path. Ordinary target-branch advancement does not require the generated PR to update because the required status-check rules use `strict_required_status_checks_policy: false`. If the immutable head remains conflict-free, its approval remains valid, and required checks pass, auto-merge can complete against the advanced base. In the narrower case where base activity actually changes the reviewed diff or merge base, GitHub can dismiss the approval and safely stall the PR. That fail-closed limitation is accepted for this automation. ### Exact branch and title allow-list ```text net11.0 + ^[automated] Merge branch 'main' => 'net11.0'$ release/...-preview7 + ^[automated] Merge branch 'net11.0' => 'release/...-preview7'$ release/...-rc1 + ^[automated] Merge branch 'net11.0' => 'release/...-rc1'$ release/...-rc2 + ^[automated] Merge branch 'net11.0' => 'release/...-rc2'$ ``` Each entry in the file contains the full literal branch and anchored regex. Targets outside this allow-list remain manual. ### Merge behavior ```yaml - enableAutoMerge: mergeMethod: merge ``` This always creates a true merge commit, never squash or rebase. Arcade relies on merge ancestry to determine what remains to flow. GitHub completes auto-merge only when the PR has no merge conflict and required checks pass. ### Required checks | ruleset | checks | Policy Service bypass | | --- | --- | --- | | `MAUI required CI checks` | `maui-pr` | **none** | | `MAUI device and UI test checks` | `maui-pr-devicetests`, `maui-pr-uitests` | pull requests only | A failing or pending `maui-pr` blocks the merge. Device/UI checks do not. `MAUI protection` has no Policy Service bypass. It requires one ordinary approval; Policy Service supplies it for the exact authenticated `Opened` events above. ### CODEOWNERS PR #36890 removes the invalid CODEOWNERS file. `Require review from Code Owners` is disabled in `MAUI protection`; the ordinary one-approval requirement remains. ### Accepted trust boundary An initial `Opened` event authorizes on exact title/base plus `github-actions[bot]` as both sender and PR author. A collaborator with repository push access could deliberately create a same-repository workflow and matching PR. Real `maui-pr` from Azure Pipelines integration 9426 must still pass, but there is no additional human review under the intentionally ordinary one-review policy. This tradeoff is accepted for these exact forward-merge target pairs. The immutable-snapshot gate prevents later human content from being reapproved through synchronization. No new App is installed and no bypass is added to `MAUI protection` or the `maui-pr` ruleset. ### Verification - Both caller workflows pass `actionlint`. - All three changed YAML files parse successfully. - The live target resolver returns `release/11.0.1xx-preview7`. - Exact App/head/base/same-repository queries identify #36886 (`main => net11.0`) and #36880 (`net11.0 => release/11.0.1xx-preview7`). - The semantic rollout check rejects the current old `net11.0` workflow and accepts matching safety-critical sections. - Official GitHub documentation confirms that `workflow_dispatch` events created with `GITHUB_TOKEN` start workflow runs; the dispatched event skips the schedule-only job. - The Policy Service file parses and GitOps schema validation runs on every update. - The live `MAUI protection` settings and effective non-strict required-status-check rules were reverified on 2026-07-31. ### Issues Fixed None; infrastructure automation. --------- Co-authored-by: PureWeen <223556219+Copilot@users.noreply.github.com> Copilot-Session: 1b2b2dd6-bf5f-4179-8a8f-c4c85b9bce26
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
6 participants
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.
I detected changes in the net11.0 branch which have not been merged yet to release/11.0.1xx-preview7. I'm a robot and am configured to help you automatically keep release/11.0.1xx-preview7 up to date, so I've opened this PR.
This PR merges commits made on net11.0 by the following committers:
Instructions for merging from UI
This PR will not be auto-merged. When pull request checks pass, complete this PR by creating a merge commit, not a squash or rebase commit.
If this repo does not allow creating merge commits from the GitHub UI, use command line instructions.
Instructions for merging via command line
Run these commands to merge this pull request from the command line.
or if you are using SSH
After PR checks are complete push the branch
Instructions for resolving conflicts
Instructions for updating this pull request
Contributors to this repo have permission update this pull request by pushing to the branch 'merge/net11.0-to-release/11.0.1xx-preview7'. This can be done to resolve conflicts or make other changes to this pull request before it is merged.
The provided examples assume that the remote is named 'origin'. If you have a different remote name, please replace 'origin' with the name of your remote.
or if you are using SSH
Contact .NET Core Engineering (dotnet/dnceng) if you have questions or issues.
Also, if this PR was generated incorrectly, help us fix it. See https://github.com/dotnet/arcade/blob/main/.github/workflows/scripts/inter-branch-merge.ps1.