[Windows] Lifecycle: Add app activation event

[mattleibow]

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 from this PR and let us know in a comment if this change resolves your issue. Thank you!

Root Cause

On Windows, MAUI exposed launch and window lifecycle hooks but not the underlying AppActivationArguments payload. That made single-instance redirect, protocol or file activation, and follow-on Windows auth work harder to handle cleanly from MauiProgram without app-specific plumbing.

Description of Change

This PR adds a new Windows lifecycle hook:

• WindowsLifecycle.OnAppActivation(UI.Xaml.Application, AppActivationArguments) -> bool
• IWindowsLifecycleBuilder.OnAppActivation(...)

MauiWinUIApplication now:

• captures the initial AppInstance.GetActivatedEventArgs() payload,
• registers once for AppInstance.GetCurrent().Activated,
• raises the new lifecycle event once MAUI services are available,
• respects the handler return value so apps can mark an activation as handled and suppress the default launch flow when appropriate.

The Controls sample demonstrates using this from MauiProgram to keep the app single-instanced, redirect later launches back into the running instance, and re-activate the existing MAUI window. The redirected losing instance follows the WinAppSDK single-instance pattern and terminates immediately after RedirectActivationToAsync(...).

Key Technical Details

• Initial activation is raised after _services = applicationContext.Services so lifecycle handlers can actually run.
• Redirected activations and later re-activations flow through the same OnAppActivation hook.
• Registration is guarded so AppInstance.Activated is only subscribed once.

What NOT to Do (for future agents)

• ❌ Don't call the activation lifecycle hook before _services exists - it becomes a no-op because the lifecycle pipeline has not been built yet.
• ❌ Don't bake WebAuthenticator-specific behavior into MauiWinUIApplication - this PR intentionally keeps the API generic.
• ❌ Don't require a custom Windows Program.cs just to observe app activation in a MAUI app - the goal here is a reusable lifecycle event from MauiProgram.

Issues Fixed

Related to #9973

Testing

• dotnet build src\Controls\samples\Controls.Sample\Maui.Controls.Sample.csproj -f net10.0-windows10.0.20348.0 /p:RestoreIgnoreFailedSources=true /p:NuGetAudit=false /p:WarningsNotAsErrors=NU1301;NU1801 /p:TreatWarningsAsErrors=false
• dotnet test src\Core\tests\UnitTests\Core.UnitTests.csproj --filter LifecycleEventsTests /p:RestoreIgnoreFailedSources=true /p:NuGetAudit=false /p:WarningsNotAsErrors=NU1301;NU1801 /p:TreatWarningsAsErrors=false

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 34870

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 34870"

[Copilot]

Pull request overview

Adds a Windows lifecycle event hook for rich app activation (AppActivationArguments) so apps can handle initial and redirected activations (protocol/file/single-instance redirection) in a consistent way via lifecycle events, and updates the Controls sample to demonstrate single-instance redirection + activation logging. This PR also includes repo-wide dependency-flow/tooling updates (SDK/Arcade/Helix, Xcode requirement, feeds, etc.).

Changes:

• Add WindowsLifecycle.OnAppActivation + builder extension, and wire activation dispatching into MauiWinUIApplication (initial activation + redirected activations).
• Update Controls.Sample (Windows) to use a custom Program.Main for single-instance redirection and to log the activation kind via the new lifecycle hook.
• Update tooling/dependencies/CI configuration (global.json/Versions.props/Version.Details.xml/NuGet feeds/pool and Xcode settings) and adjust some tests accordingly.

Reviewed changes

Copilot reviewed 30 out of 30 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
src/Workload/workloads.csproj	Updates workload project TFM to net10.0.
src/TestUtils/src/Microsoft.Maui.IntegrationTests/WindowsTemplateTest.cs	Disables DotNetPrevious test cases (with TODO).
src/TestUtils/src/Microsoft.Maui.IntegrationTests/SimpleTemplateTest.cs	Disables DotNetPrevious test cases (with TODO).
src/TestUtils/src/Microsoft.Maui.IntegrationTests/AndroidTemplateTests.cs	Disables DotNetPrevious test cases (with TODO).
src/Templates/src/cgmanifest.json	Updates template cgmanifest package versions.
src/Core/tests/UnitTests/LifecycleEvents/LifecycleEventsTests.cs	Adds unit test verifying Windows OnAppActivation lifecycle registration/invocation.
src/Core/src/PublicAPI/net-windows/PublicAPI.Unshipped.txt	Declares new public API surface for Windows activation lifecycle hook.
src/Core/src/Platform/Windows/MauiWinUIApplication.cs	Dispatches rich activation args through lifecycle events (initial + redirected activations).
src/Core/src/LifecycleEvents/Windows/WindowsLifecycleBuilderExtensions.cs	Adds OnAppActivation(...) lifecycle builder extension method.
src/Core/src/LifecycleEvents/Windows/WindowsLifecycle.cs	Adds WindowsLifecycle.OnAppActivation delegate.
src/Controls/samples/Controls.Sample/Platforms/Windows/Program.cs	Adds custom Windows entry point demonstrating single-instance redirection.
src/Controls/samples/Controls.Sample/MauiProgram.cs	Hooks sample logging to WindowsLifecycle.OnAppActivation.
src/Controls/samples/Controls.Sample/Maui.Controls.Sample.csproj	Defines DISABLE_XAML_GENERATED_MAIN for Windows to support custom entry point.
src/BlazorWebView/tests/DeviceTests/Elements/BlazorWebViewTests.RequestInterception.cs	Skips a flaky theory due to external dependency.
NuGet.config	Updates/expands package sources (dependency-flow + manual feeds).
global.json	Updates .NET SDK tooling and Arcade/Helix SDK versions.
eng/Versions.props	Updates repo versioning (ci label, runtime/extensions versions, Android/macios package versions).
eng/Version.Details.xml	Updates dependency flow versions/shas for SDK/runtime/android/macios/extensions/arcade toolset.
eng/pipelines/common/variables.yml	Updates required Xcode version to 26.2.0.
eng/pipelines/ci.yml	Updates macOS pool selection/conditions to accommodate Xcode 26.2 availability constraints.
eng/common/tools.ps1	Adjusts web requests and VS requirement probing logic in tooling script.
eng/common/templates/variables/pool-providers.yml	Updates documented Windows image override reference.
eng/common/post-build/nuget-verification.ps1	Adjusts Invoke-WebRequest usage for nuget.exe download.
eng/common/internal-feed-operations.ps1	Adjusts Invoke-WebRequest usage for cred provider bootstrap script.
eng/common/cross/x86/tizen/tizen.patch	Adds patch for Tizen cross toolchain libc linker script.
eng/common/cross/x64/tizen/tizen.patch	Adds patch for Tizen cross toolchain libc linker script.
eng/common/cross/arm64/tizen/tizen.patch	Adds patch for Tizen cross toolchain libc linker script.
eng/common/cross/arm/tizen/tizen.patch	Adds patch for Tizen cross toolchain libc linker script.
eng/common/core-templates/post-build/post-build.yml	Updates publishing pool image/demands from vs2019 to vs2022.
eng/common/core-templates/job/publish-build-assets.yml	Updates publishing pool image from vs2019 to vs2022.

[github-actions]

🧪 PR Test Evaluation

Overall Verdict: ⚠️ Tests need improvement

The unit test correctly covers the happy path (multi-handler registration, both handlers invoked, wasHandled accumulation), but is missing the "not handled" edge case — which is actually the most critical path in MauiWinUIApplication.OnLaunched.

👍 / 👎 — Was this evaluation helpful? React to let us know!

📊 Expand Full Evaluation

PR Test Evaluation Report

PR: #34870 — [Windows] Add app activation lifecycle event
Test files evaluated: 1 (LifecycleEventsTests.cs — CanAddWindowsOnAppActivationLifecycleEvent)
Fix files: 3 (WindowsLifecycle.cs, WindowsLifecycleBuilderExtensions.cs, MauiWinUIApplication.cs)

---

Overall Verdict

⚠️ Tests need improvement

The unit test is well-structured and consistent with the existing suite, but it only covers the "at least one handler returns true" scenario. The "all handlers return false" case is untested, which is the exact path that controls whether the default window creation in MauiWinUIApplication.OnLaunched proceeds.

---

1. Fix Coverage — ⚠️

The test covers the primary happy path: registering multiple OnAppActivation handlers, verifying both are invoked, and checking that wasHandled becomes true when any handler returns true. This directly exercises the new delegate and builder extension.

However, the MauiWinUIApplication integration — specifically the OnLaunched early-return guard (if (activatedEventArgs is not null && OnAppActivation(activatedEventArgs)) return;) and the RegisterForAppActivation / OnAppInstanceActivated dispatch path — are not tested at all. These are the practical "does the fix actually work" behaviors.

Note: The platform runtime integration is hard to unit-test without a real Windows runtime (no way to mock AppInstance.GetCurrent()), so this gap is partially expected.

2. Edge Cases & Gaps — ⚠️

Covered:

• Multiple handlers are all invoked (no early-exit on first match)
• wasHandled is correctly accumulated via OR logic when any handler returns true
• Registration check via ContainsEvent

Missing:

• "Not handled" path — no test for when all handlers return false (or no handlers are registered). This is critical: MauiWinUIApplication.OnLaunched uses the return value to decide whether to suppress window creation. A test confirming wasHandled = false ensures the default launch path isn't accidentally blocked.
• Single handler returning false — edge case but simple to add
• Single handler returning true — similarly simple to verify
• Redirected activation path (OnAppInstanceActivated → DispatcherQueue.TryEnqueue) — not testable without Windows runtime, acceptable gap

3. Test Type Appropriateness — ✅

Current: Unit Test (xUnit, #if WINDOWS)
Recommendation: Correct choice. The event registration and delegation logic is pure C# and doesn't need a platform context to verify. This matches the pattern of all other CanAdd*LifecycleEvent tests in the file.

4. Convention Compliance — ✅

• ✅ [Fact] attribute (xUnit)
• ✅ #if WINDOWS guard (correct — the delegate types reference Windows API types)
• ✅ File/class naming consistent with existing tests
• ✅ No anti-patterns detected

5. Flakiness Risk — ✅ Low

Pure unit test, no Appium, no platform I/O, no delays. Very stable.

6. Duplicate Coverage — ✅ No duplicates

No similar existing tests found. This is new API surface with new test coverage.

7. Platform Scope — ✅

The fix is Windows-only (all 3 changed files are Windows-specific). The test is guarded with #if WINDOWS. Appropriate.

8. Assertion Quality — ⚠️

The assertions are good for the scenario being tested:

• Assert.True(service.ContainsEvent(nameof(...))) — verifies registration ✅
• Assert.True(firstHandlerCalled) / Assert.True(secondHandlerCalled) — verifies both handlers invoked ✅
• Assert.True(wasHandled) — verifies OR-accumulation when one handler returns true ✅

But the absence of a Assert.False(wasHandled) scenario (when all handlers return false) means the accumulation logic is only half-tested. The || wasHandled in the invocation loop could be dropped and the existing test would still pass.

9. Fix-Test Alignment — ✅

The test exercises exactly the new delegate type and builder extension added by the fix. The event name, delegate signature, and registration flow match what WindowsLifecycle.cs and WindowsLifecycleBuilderExtensions.cs expose.

---

Recommendations

1. Add a "not handled" test case — Add a second [Fact] (or convert to [Theory]) testing the scenario where all registered handlers return false. This validates that the MauiWinUIApplication.OnLaunched will NOT suppress window creation when no handler claims the activation:

   [Fact]
   public void OnAppActivationReturnsFalseWhenNoHandlerHandlesIt()
   {
       var handlerCalled = false;
       var mauiApp = MauiApp.CreateBuilder()
           .ConfigureLifecycleEvents(builder =>
               builder.AddWindows(w => w.OnAppActivation((app, args) => { handlerCalled = true; return false; })))
           .Build();
       var service = mauiApp.Services.GetRequiredService(ILifecycleEventService)();
       var wasHandled = false;
       service.InvokeEvents(WindowsLifecycle.OnAppActivation)(nameof(WindowsLifecycle.OnAppActivation), del =>
           wasHandled = del(null!, null!) || wasHandled);
       Assert.True(handlerCalled);
       Assert.False(wasHandled); // Window creation should NOT be suppressed
   }

2. Consider a test with no handlers — Verify that InvokeEvents with zero registered handlers results in wasHandled = false. This guards against future regressions where the default value is accidentally changed.

3. Long-term — The MauiWinUIApplication integration (activation suppressing the default window, the AppInstance.Activated subscription) would benefit from a Windows device test or integration test. This is low priority given the complexity, but worth tracking.

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• dc.services.visualstudio.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "dc.services.visualstudio.com"

See Network Configuration for more information.

Note

🔒 Integrity filtering filtered 1 item

Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.

• pr:[Windows] Lifecycle: Add app activation event #34870 (pull_request_read: Resource 'pr:[Windows] Lifecycle: Add app activation event #34870' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)

🧪 Test evaluation by Evaluate PR Tests

[github-actions]

🧪 PR Test Evaluation

Overall Verdict: ⚠️ Tests need improvement

The PR adds a correct unit test for lifecycle event registration and invocation, but misses several edge cases for the bool return/handled semantics and the MauiWinUIApplication integration layer.

👍 / 👎 — Was this evaluation helpful? React to let us know!

📊 Expand Full Evaluation

PR Test Evaluation Report

PR: #34870 — [Windows] Add app activation lifecycle event
Test files evaluated: 1 (LifecycleEventsTests.cs)
Fix files: 3 (WindowsLifecycle.cs, WindowsLifecycleBuilderExtensions.cs, MauiWinUIApplication.cs)

---

Overall Verdict

⚠️ Tests need improvement

The unit test verifies lifecycle event registration and invocation, but important edge cases around the bool-returning handled pattern and the MauiWinUIApplication integration (early return in OnLaunched, RegisterForAppActivation, LaunchActivatedEventArgs) are not covered.

---

1. Fix Coverage — ⚠️

The test exercises event registration via windows.OnAppActivation(), confirms ContainsEvent returns true, and invokes handlers — checking that both are called and wasHandled reflects the OR-combination. This covers the lifecycle infrastructure layer well.

However, the MauiWinUIApplication integration is not covered:

• The OnLaunched re-launch path (second-instance case) calls OnAppActivation and skips OnLaunched event if handled — not tested.
• The initial launch path similarly calls OnAppActivation before CreatePlatformWindow — not tested.
• The RegisterForAppActivation / AppInstance.GetCurrent().Activated subscription chain is not tested.
• The LaunchActivatedEventArgs property being set at the top of OnLaunched is not tested.

The test uses null! for both parameters (del(null!, null!)) — adequate for unit testing the dispatch mechanism but not for validating parameter-forwarding correctness.

2. Edge Cases & Gaps — ⚠️

Covered:

• Multiple handlers registered and all invoked
• wasHandled is true when at least one handler returns true
• The registered handlers are iterable via ContainsEvent

Missing:

• No handlers registered — wasHandled should remain false, ContainsEvent should return false.
• All handlers return false — wasHandled should be false; this scenario is not tested.
• First handler returns true, second handler still called — The current test uses the order [returns-false, returns-true]. The test never exercises the [returns-true, returns-false] case, which would confirm that ALL handlers are always invoked (not short-circuited). Since InvokeLifecycleEvents uses foreach, short-circuiting is not a concern architecturally, but this is worth explicitly verifying given the || in OnAppActivation.
• OnLaunched early-return behavior — No test verifies that OnLaunched event is suppressed when OnAppActivation returns true.

3. Test Type Appropriateness — ✅

Current: Unit Test
Recommendation: Same — unit test is the correct choice here.

The lifecycle event registration and invocation infrastructure is pure logic (no native API dependency). The test correctly uses the ILifecycleEventService directly, which is the same pattern used by all other lifecycle event tests in the file. The more platform-integrated behavior (interacting with AppInstance.GetCurrent()) would require a device test, but that's hard to mock and is reasonable to leave out for now.

4. Convention Compliance — ✅

The automated script found 0 convention issues.

• [Fact] attribute present ✅
• Correctly scoped under #if WINDOWS ✅
• Follows the same pattern as CanAddAndroidOnKeyDownLifecycleEvent and other sibling tests ✅

5. Flakiness Risk — ✅ Low

Synchronous unit test with no timers, delays, platform I/O, or async operations. No flakiness risk.

6. Duplicate Coverage — ✅ No duplicates

This is a new API (OnAppActivation). No existing tests cover the same scenario.

7. Platform Scope — ✅

Fix is Windows-only (3 Windows-platform files). Test is gated with #if WINDOWS. No other platforms are affected.

8. Assertion Quality — ⚠️

Assertions are readable and meaningful for the happy path:

• Assert.True(firstHandlerCalled) — confirms all handlers called
• Assert.True(secondHandlerCalled) — confirms all handlers called
• Assert.True(wasHandled) — confirms OR-semantics

Concern: There is no assertion for wasHandled = false (all-return-false case), and no negative assertion testing ContainsEvent returns false before registration or after wasHandled should be false. The test doesn't verify order-independence of the OR result.

9. Fix-Test Alignment — ⚠️

The test targets the lifecycle event dispatch infrastructure (correct path for the OnAppActivation delegate). However, the MauiWinUIApplication.OnAppActivation virtual method, the AppInstance.Activated subscription, and the OnLaunched branching logic are the core behavior introduced by this PR — these are entirely untested. While mocking AppInstance is impractical, the MauiWinUIApplication.OnAppActivation method itself could potentially be tested in isolation with a mock IServiceProvider.

---

Recommendations

1. Add "no handlers / all return false" test — Add a test case where all registered handlers return false and verify wasHandled is false after invocation. This validates the negative path of the handled-pattern semantics.

2. Add "first returns true, second still called" test — Swap the handler order (first returns true, second returns false) and assert both handlers are still called. This explicitly verifies that activation event handlers are not short-circuited, which is important for the multi-instance app activation use case.

3. Consider a test for MauiWinUIApplication.OnAppActivation integration — Even a simple test that subclasses MauiWinUIApplication, overrides OnAppActivation, and verifies the virtual dispatch chain works correctly would increase confidence in the integration. The InvokeLifecycleEvents lambda in the virtual method could be extracted or made mockable.

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• dc.services.visualstudio.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "dc.services.visualstudio.com"

See Network Configuration for more information.

Note

🔒 Integrity filtering filtered 1 item

Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.

• pr:[Windows] Lifecycle: Add app activation event #34870 (pull_request_read: Resource 'pr:[Windows] Lifecycle: Add app activation event #34870' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)

🧪 Test evaluation by Evaluate PR Tests

[github-actions]

🧪 PR Test Evaluation

Overall Verdict: ⚠️ Tests need improvement

The lifecycle registration is well-tested, but the application-level integration in MauiWinUIApplication.cs — the most critical behavioral change — has no test coverage.

👍 / 👎 — Was this evaluation helpful? React to let us know!

📊 Expand Full Evaluation

PR Test Evaluation Report

PR: #34870 — [Windows] Add app activation lifecycle event
Test files evaluated: 1 (LifecycleEventsTests.cs)
Fix files: 4 (WindowsLifecycle.cs, WindowsLifecycleBuilderExtensions.cs, MauiWinUIApplication.cs, Controls.Sample/MauiProgram.cs)

---

Overall Verdict

⚠️ Tests need improvement

The unit test covers the lifecycle service registration layer well (event registration, multi-handler invocation, return-value OR logic), but the behavioral logic added to MauiWinUIApplication.cs — including the "skip window creation" short-circuit, the RegisterForAppActivation guard, and the subsequent-launch path — has no test coverage at all.

---

1. Fix Coverage — ⚠️ Partial

The test exercises the lifecycle service layer (via ILifecycleEventService) and verifies that OnAppActivation can be registered and invoked with both handlers called and the bool return OR'd correctly. This is good.

However, the most significant behavioral changes are in MauiWinUIApplication.cs:

• RegisterForAppActivation() with the _isRegisteredForAppActivation guard
• OnAppActivation(args) being called in OnLaunched before CreatePlatformWindow — the core short-circuit
• The late-launch path (when _application != null) also calling OnAppActivation
• AppInstance.GetCurrent().Activated event subscription

None of these are covered by the existing test.

2. Edge Cases & Gaps — ⚠️ Gaps present

Covered:

• Multiple handlers are both called
• Return value OR logic (wasHandled = true if any handler returns true)
• Event name registration (ContainsEvent)
• Handlers can accept null! args (tested implicitly)

Missing:

• Skip-window-creation behavior: When OnAppActivation returns true, does MauiWinUIApplication properly short-circuit CreatePlatformWindow? This is the core behavior of the feature.
• Late-launch path: The branch inside OnLaunched when _application != null && _services != null (used for subsequent launches from other instances) isn't tested.
• No handlers registered: What happens when OnAppActivation is invoked but no handlers are registered? Should return false gracefully.
• Double-registration guard: The _isRegisteredForAppActivation flag preventing duplicate subscriptions isn't explicitly tested.
• Handler returning false: Only a mix of true/false is tested — but no test where all handlers return false (should result in wasHandled = false).

3. Test Type Appropriateness — ✅ Correct for what it covers

Current: Unit Test
Recommendation: The unit test is the right choice for the lifecycle service layer. The uncovered integration behavior in MauiWinUIApplication.cs is harder to unit-test (requires mocking AppInstance.GetCurrent()), but a device test or at minimum a subclass-based unit test overriding OnAppActivation could cover the window-creation skip behavior.

The sample code in MauiProgram.cs demonstrates real usage but is not a test.

4. Convention Compliance — ✅ No issues

• [Fact] attribute (xUnit) ✅
• #if WINDOWS guard (appropriate for Windows-only test) ✅
• Descriptive test name CanAddWindowsOnAppActivationLifecycleEvent ✅
• No convention issues detected by automated script

5. Flakiness Risk — ✅ Low

Pure unit test with no I/O, async operations, platform APIs, or timing dependencies. Very low flakiness risk.

6. Duplicate Coverage — ✅ No duplicates

No existing similar tests found. The OnAppActivation event is new and there are other CanAdd*LifecycleEvent tests following the same pattern.

7. Platform Scope — ✅ Appropriate

The fix is entirely Windows-specific. The test is correctly guarded with #if WINDOWS. The PublicAPI.Unshipped.txt is also Windows-specific (net-windows).

8. Assertion Quality — ✅ Good

Assertion	Quality	Notes
Assert.True(service.ContainsEvent(...))	✅ Specific	Confirms registration
Assert.True(firstHandlerCalled)	✅ Specific	Both handlers invoked
Assert.True(secondHandlerCalled)	✅ Specific	Both handlers invoked
Assert.True(wasHandled)	✅ Specific	Return value OR logic

All assertions are meaningful and specific to the behavior being tested.

9. Fix-Test Alignment — ⚠️ Partial mismatch

The test aligns with WindowsLifecycle.cs and WindowsLifecycleBuilderExtensions.cs (the lifecycle service API). It does not align with the changes in MauiWinUIApplication.cs, which represent the largest and most consequential portion of the fix. The actual integration — "when activation is handled, don't create the window" — is untested.

---

Recommendations

1. Add a test for the skip-window-creation behavior: Create a unit test (or device test) that verifies when an OnAppActivation handler returns true, MauiWinUIApplication does not proceed to CreatePlatformWindow. This is the most important missing coverage. A subclass approach overriding OnAppActivation could work without needing to mock native Windows APIs.

2. Add a test for "no handlers returns false": Add a test case with zero OnAppActivation handlers registered to confirm OnAppActivation returns false (and window creation proceeds normally). This is the most common path (most apps won't use this event).

3. Add a test for the late-launch path: Add a test that exercises the _application != null branch (subsequent activation), verifying that OnAppActivation is invoked but OnLaunched is NOT re-fired.

Warning

⚠️ Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• dc.services.visualstudio.com

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "dc.services.visualstudio.com"

See Network Configuration for more information.

Note

🔒 Integrity filtering filtered 1 item

Integrity filtering activated and filtered the following item during workflow execution.
This happens when a tool call accesses a resource that does not meet the required integrity or secrecy level of the workflow.

• pr:[Windows] Lifecycle: Add app activation event #34870 (pull_request_read: Resource 'pr:[Windows] Lifecycle: Add app activation event #34870' has lower integrity than agent requires. Agent would need to drop integrity tags [unapproved:all approved:all] to trust this resource.)

🧪 Test evaluation by Evaluate PR Tests

[mattleibow]

Superseded by #34883 to restart review on a clean thread.