Is there an existing issue for this?
Describe the bug
The JavaScript interop analyzer provides automatic code fixes for certain warnings, but the availability is inconsistent and limited:
BL0015 ("Make [JSInvokable] method public"):
- Code fix IS available in Razor Class Library (.cs class files)
- Code fix IS NOT available in Razor component (.razor) files in Server and Client projects
- Developers using .razor components must manually edit code, while RCL developers get automatic fixes for the same warning
BL0016 ("Guard JavaScript interop calls"):
- Code fix is NOT available in any project type (Server, Client, or RCL)
- Developers must manually add try/catch blocks or restructure code to move calls to OnAfterRender
This creates a poor developer experience: the analyzer identifies the problem but provides no automated solution in most scenarios.
Expected Behavior
- BL0015 code fix should work in .razor component files (Razor components in Server and Client projects), just as it does in RCL files
- BL0016 code fix should be available (the IDE should provide a suggestion for wrapping in try/catch)
At the very least, both warnings should offer consistent code fix availability across all project types.
Steps To Reproduce
Steps To Reproduce
- Create a Blazor Web App targeting .NET 11 with Interactive Server render mode
- In a .razor component file, create a private method with
[JSInvokable] attribute:
[JSInvokable]
private async Task MyPrivateMethod()
{
// Code here
}
- Build the project - BL0015 warning appears
- In Visual Studio, click on the warning and look for Quick Actions (Alt+.)
- Observe: No automatic code fix is offered
Contrast with RCL:
- Create the same private
[JSInvokable] method in an RCL .cs class file
- Build - BL0015 warning appears
- In Visual Studio, click on the warning and look for Quick Actions (Alt+.)
- Observe: "Make [JSInvokable] method public" code fix IS available
Exceptions (if any)
No exceptions are thrown. The issue is purely about missing IDE code fix support.
.NET Version
11.0.100-preview.7.26381.103
Anything else?
Test Environments:
- Visual Studio 2022 (latest)
- Windows 11
- .NET 11 Preview 7
Affected Code Patterns:
| Warning |
Project Type |
Code Fix |
Impact |
| BL0015 |
RCL (.cs class) |
✓ Available |
Automatic fix works |
| BL0015 |
Server (.razor) |
✗ Not Available |
Manual fix required |
| BL0015 |
Client (.razor) |
✗ Not Available |
Manual fix required |
| BL0016 |
All projects |
✗ Not Available |
Manual fix required |
Reproduction Repository:
Additional Context
The inconsistency between RCL and component code fixes creates developer confusion. Developers expect that if a warning exists in the IDE, there should be a way to fix it automatically. When fixes work in one project type but not another for the same warning, it feels like a gap in the analyzer implementation.
For BL0016, having no code fix at all means developers must learn the correct pattern from documentation rather than getting guidance from the IDE when they violate it. An automatic suggestion to wrap calls in try/catch would improve the developer experience significantly.
Is there an existing issue for this?
Describe the bug
The JavaScript interop analyzer provides automatic code fixes for certain warnings, but the availability is inconsistent and limited:
BL0015 ("Make [JSInvokable] method public"):
BL0016 ("Guard JavaScript interop calls"):
This creates a poor developer experience: the analyzer identifies the problem but provides no automated solution in most scenarios.
Expected Behavior
At the very least, both warnings should offer consistent code fix availability across all project types.
Steps To Reproduce
Steps To Reproduce
[JSInvokable]attribute:Contrast with RCL:
[JSInvokable]method in an RCL .cs class fileExceptions (if any)
No exceptions are thrown. The issue is purely about missing IDE code fix support.
.NET Version
11.0.100-preview.7.26381.103
Anything else?
Test Environments:
Affected Code Patterns:
Reproduction Repository:
Additional Context
The inconsistency between RCL and component code fixes creates developer confusion. Developers expect that if a warning exists in the IDE, there should be a way to fix it automatically. When fixes work in one project type but not another for the same warning, it feels like a gap in the analyzer implementation.
For BL0016, having no code fix at all means developers must learn the correct pattern from documentation rather than getting guidance from the IDE when they violate it. An automatic suggestion to wrap calls in try/catch would improve the developer experience significantly.