Allow access modifiers for Razor component classes (e.g., internal for Blazor components)

[FelipeCostaGualberto]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Razor components defined in .razor files are always generated as public classes. There is no supported way to declare a component as internal (or another modifier like private and file). This results in polluted RCL projects because its components "helpers" are shipped as public.

• Current workaround using EditorBrowsable(Never) do not enforce encapsulation.
• Writing components with BuildRenderTree accepts modifiers, but lose Razor syntax.

Describe the solution you'd like

Add a Razor directive to control the generated component class accessibility. If not present, component is public by default.

Example in .razor file:

`@accessibility internal`

If using a backing .razor.cs file, the developer must declare the class also with internal.

Additional context

No response

[FelipeCostaGualberto]

It seems this was debated in the old Blazor repository here, but conversation was limited to collaborators.

[javiercn]

Thanks for contacting us.

This is not a direction we plan to take for several reasons:

Ecosystem Breaking Change Impact
This change represents a significant breaking change that affects the broader ASP.NET Core ecosystem. Many libraries, tools, and third-party components currently rely on the existing component visibility model. Altering this fundamental assumption disrupts the established patterns that developers and library authors have built their solutions around.

Design Consistency Concerns
This change introduces inconsistency with other design decisions across the ASP.NET framework. The current public-by-default approach aligns with established conventions throughout the platform, like Controllers, Razor Pages and so on, creating a cohesive developer experience. Moving away from this pattern creates cognitive overhead as developers need to navigate different visibility rules across different parts of the framework.

Runtime and Tooling Impact
The assumption that components are public is deeply embedded across multiple layers of the runtime and tooling ecosystem. This includes:

• Build tools and analyzers that process components
• IDE support and IntelliSense features
• Third-party libraries that inspect or extend components
• Testing frameworks and mocking libraries
• Code generation tools

Changing this fundamental assumption requires substantial modifications across these layers, which introduces complexity and potential instability.

Using EditorBrowsable is acceptable. If you want to be stricter you could author an analyzer to block the usage altogether across assemblies.

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

[FelipeCostaGualberto]

Thanks. While I understand the reason as this is not planned, I can't let this without a "fight":

1 - There’s already a supported way that proves the runtime can live with non-public components today with no issues (if you build a component by overriding BuildRenderTree and then using <DynamicComponent>).

2 - Even tough you already said such change would cause significant impact in .NET ecossystem, I'm sorry I'm being stubborn because it would keep components public by default policy.

3 - Controllers/Pages being public by default is fine for application code, but component libraries benefit from explicit, minimal public surfaces (this is a standard Microsoft guideline for library design and versioning).

4 - Competitors: React and Angular allow something like internal in C#.

I think this feature is the only thing I miss from Blazor in all these years, since I'm an early adopter.

Thanks.