Skip to content

[release/10.0] [Blazor] OwningComponentBase Dispose method in .NET 10 gets back the original behavior - #64794

Merged
lewing merged 12 commits into
release/10.0from
backport/pr-64695-to-release/10.0
May 18, 2026
Merged

[release/10.0] [Blazor] OwningComponentBase Dispose method in .NET 10 gets back the original behavior#64794
lewing merged 12 commits into
release/10.0from
backport/pr-64695-to-release/10.0

Conversation

@github-actions

@github-actions github-actions Bot commented Dec 16, 2025

Copy link
Copy Markdown
Contributor

Backport of #64695 to release/10.0

/cc @javiercn @ilonatommy

Restore Dispose(bool disposing) with disposing=true on async disposal for Blazor components.

Description

In .NET 9, disposing a Blazor component would call IDisposable.Dispose(), which then invoked Dispose(bool disposing) with disposing=true. This allowed user overrides of Dispose(bool disposing) to execute necessary cleanup logic for managed resources. However, in .NET 10, after introducing IAsyncDisposable support (PR #62583), the framework began invoking IAsyncDisposable.DisposeAsync(), which followed the typical .NET dispose pattern and called Dispose(false). This caused user code that depended on disposing=true to break, as DisposeAsync() was now incorrectly signaling a non-disposing context.

This fix ensures backward compatibility by making DisposeAsync() call Dispose(true), just as in .NET 9 and earlier. Additionally, the IsDisposed = true assignment has been removed from DisposeAsyncCore(), and its handling is now consolidated within Dispose(bool disposing) for consistency and to prevent double-disposal.

Fixes #64669

Customer Impact

Without this fix, users overriding Dispose(bool disposing) in Blazor components could see their cleanup logic silently skipped in .NET 10, leading to resource leaks or unexpected behavior. This change restores the expected contract and makes async disposal consistent and safe for component authors who rely on the documented pattern.

Regression?

  • Yes
  • No

Regressed from: .NET 9

Risk

  • High
  • Medium
  • Low

This change restores prior contract and behavior; automated tests confirm idempotency and compatibility. Since the implementation centralizes disposal logic, risk of introducing regressions is low.

Verification

  • Manual (required)
  • Automated

Packaging changes reviewed?

  • Yes
  • No
  • N/A

@github-actions
github-actions Bot requested a review from a team as a code owner December 16, 2025 12:42
@javiercn javiercn added this to the 10.0.x milestone Dec 16, 2025
@ilonatommy ilonatommy added the area-blazor Includes: Blazor, Razor Components label Dec 17, 2025
@ilonatommy ilonatommy self-assigned this Dec 17, 2025
@ilonatommy
ilonatommy requested a review from javiercn December 17, 2025 14:33
@dotnet-policy-service dotnet-policy-service Bot added the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label Dec 24, 2025
@neissljanik

Copy link
Copy Markdown

Hi, is there any ETA for when this PR will be merged? I understand the issue is still not fixed in .NET 10?

@neissljanik

Copy link
Copy Markdown

@javiercn @ilonatommy ?

@oroztocil oroztocil added the Servicing-consider Shiproom approval is required for the issue label May 18, 2026
@oroztocil oroztocil removed the pending-ci-rerun When assigned to a PR indicates that the CI checks should be rerun label May 18, 2026
@lewing lewing added Servicing-approved Shiproom has approved the issue and removed Servicing-consider Shiproom approval is required for the issue labels May 18, 2026
@lewing
lewing merged commit 83ebcde into release/10.0 May 18, 2026
28 checks passed
@lewing
lewing deleted the backport/pr-64695-to-release/10.0 branch May 18, 2026 17:55
@dotnet-policy-service dotnet-policy-service Bot modified the milestones: 10.0.x, 10.0.9 May 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area-blazor Includes: Blazor, Razor Components Servicing-approved Shiproom has approved the issue

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants