API Proposal: InputFile.Dispose(bool) virtual dispose pattern

[javiercn]

Background and Motivation

InputFile previously used explicit interface implementation for IDisposable.Dispose(), making it difficult for derived classes to properly dispose resources without reflection. A user implementing a derived class for handling cancel events (see #58118) had to use reflection to dispose _jsCallbacksRelay. The standard .NET dispose pattern with protected virtual void Dispose(bool) enables derived classes to extend disposal behavior cleanly.

Source: PR #64771, fixes #64392 (also references #58118).

Proposed API

namespace Microsoft.AspNetCore.Components.Forms;

public class InputFile : ComponentBase, IDisposable
{
+    protected virtual void Dispose(bool disposing);
}

Usage Examples

public class CustomInputFile : InputFile
{
    private SomeResource _resource;

    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            _resource?.Dispose();
        }
        base.Dispose(disposing);
    }
}

Alternative Designs

Keep explicit IDisposable.Dispose() and require reflection for derived classes. This was rejected as it violates the .NET dispose pattern guidelines.

Risks

Technically a behavioral change — existing derived classes that shadow Dispose() may behave differently. However, this follows established .NET patterns (InputBase, ValidationMessage already use this pattern).

[dotnet-policy-service]

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[github-actions]

Triage Summary

Area: area-blazor — already labeled; proposal is for InputFile in Microsoft.AspNetCore.Components.Forms, which is part of Blazor/Razor Components.

Type: api-proposal — follows the formal API proposal template, proposes adding protected virtual void Dispose(bool disposing) to InputFile to align with standard .NET dispose pattern.

Potential Duplicates

• [Blazor] InputFile should implement dispose pattern #64392 — Related (referenced as "fixes" target); describes the underlying problem that motivated this proposal, not a duplicate.
• [Blazor] InputFile support for cancel event #58118 — Related (referenced in issue body); describes the workaround scenario, not a duplicate.
• No open duplicates found.

Notes

• The issue already carries api-ready-for-review, indicating it has been prepared for formal API review.
• The proposal is well-scoped and consistent with existing patterns in the codebase (InputBase, ValidationMessage already use Dispose(bool)).
• No regression — this is an additive API change, not a bug fix.

Generated by Issue Triage Agent for dotnet/aspnetcore for issue #66386 · ● 166.6K · ◷

[halter73]

API Review Notes:

• Do we need async disposal support? Not really.

namespace Microsoft.AspNetCore.Components.Forms;

public class InputFile : ComponentBase, IDisposable
{
+    protected virtual void Dispose(bool disposing);
}

API Approved!