Add BL0010 analyzer: Recommend InvokeVoidAsync over InvokeAsync<object>

[Copilot]

Add BL0010 analyzer: Recommend InvokeVoidAsync over InvokeAsync

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Adds Roslyn analyzer BL0010 to detect InvokeAsync<object> and recommend InvokeVoidAsync

Description

Using InvokeAsync<object> for JS interop calls that don't return a value can cause serialization failures when JavaScript returns non-serializable values (e.g., window). This analyzer catches the antipattern at compile time.

Note: The diagnostic intentionally fires even when the result is assigned to a variable (e.g., var res = await JS.InvokeAsync<object>(...)), because object cannot be properly deserialized from JSON - the result will either be null or cause serialization errors if JavaScript returns a non-serializable value.

Changes:

• InvokeAsyncOfObjectAnalyzer.cs - Detects InvokeAsync<object> on IJSRuntime, IJSObjectReference, and in-process variants (both direct and extension method calls)
• DiagnosticDescriptors.cs - Added BL0010 descriptor (Warning, enabled by default)
• Resources.resx - Localized diagnostic strings
• InvokeAsyncOfObjectAnalyzerTest.cs - 14 unit tests

Example flagged code:

// BL0010: Use 'InvokeVoidAsync' instead of 'InvokeAsync<object>'
await jsRuntime.InvokeAsync<object>("window.open", url, "_blank");

// Correct
await jsRuntime.InvokeVoidAsync("window.open", url, "_blank");

Fixes #38549

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Consider Razor Analyzer which Recommends InvokeVoidAsync instead of InvokeAsync<object></issue_title>
<issue_description>Analyzer / Code action pattern for this scenario.

Avoid issues like: #38501 (comment)</issue_description>

Comments on the Issue (you are @copilot in this section)

@ We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our [Triage Process](https://github.com/dotnet/aspnetcore/blob/main/docs/TriageProcess.md). @ We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our [Triage Process](https://github.com/dotnet/aspnetcore/blob/main/docs/TriageProcess.md).

• Fixes Consider Razor Analyzer which Recommends InvokeVoidAsync instead of InvokeAsync<object> #38549

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[dotnet-policy-service]

Greetings! You've submitted a PR that modifies code that is shared with https://github.com/dotnet/runtime . Please make sure you synchronize this code with the changes in that repo!

[Copilot]

Pull request overview

This PR adds a new Roslyn analyzer (BL0010) that detects usage of InvokeAsync<object> in JavaScript interop calls and recommends using InvokeVoidAsync instead. This addresses a common antipattern where developers use InvokeAsync<object> for JS calls that don't return a value, which can lead to serialization failures when JavaScript returns non-serializable values like window or undefined.

Key changes:

• New analyzer that flags InvokeAsync<object> calls on IJSRuntime, IJSObjectReference, and their in-process variants
• Comprehensive test coverage with 13 test cases covering various scenarios including extension methods
• Diagnostic set as a Warning with enabled-by-default behavior

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
src/Components/Analyzers/src/InvokeAsyncOfObjectAnalyzer.cs	Implements the new BL0010 analyzer to detect InvokeAsync<object> calls on JS interop types
src/Components/Analyzers/src/DiagnosticDescriptors.cs	Adds the BL0010 diagnostic descriptor with Warning severity
src/Components/Analyzers/src/Resources.resx	Adds localized resource strings for the diagnostic title, format, and description
src/Components/Analyzers/test/InvokeAsyncOfObjectAnalyzerTest.cs	Provides comprehensive test coverage with 13 test cases for the analyzer

[Copilot]

Add #nullable enable directive after the namespace declaration to match the coding conventions used in other analyzers in this codebase. This ensures consistent nullable reference type handling across all analyzer files.

Suggested change

	#nullable enable

[Copilot]

Added #nullable enable directive in commit 61397d9.

[oroztocil]

Are we sure the diagnostic will not fire on legitimate cases where the result is not thrown away, e.g.:

var res = await JS.InvokeAsync<object>("...");

There should be tests for these cases.

[javiercn]

Are we sure the diagnostic will not fire on legitimate cases where the result is not thrown away, e.g.:

var res = await JS.InvokeAsync<object>("...");

There should be tests for these cases.

@copilot add a test for this if there isn't one. If there is one point out the test name.

[Copilot]

Are we sure the diagnostic will not fire on legitimate cases where the result is not thrown away, e.g.:

...

Added test DiagnosticForInvokeAsyncWithObjectReturnAssignedToVariable in commit 61397d9. The diagnostic intentionally fires even when the result is assigned to a variable because using InvokeAsync<object> is problematic regardless - object cannot be properly deserialized from JSON, and the result will either be null or cause serialization errors if JavaScript returns a non-serializable value like window.

[oroztocil]

I see, I did not understand the reasoning from the description at first.