BL0004 ("Component parameter should be public") error should also accept internal

[SteveSandersonMS]

There are legit reasons to want to have internal-typed domain objects and to use them as component parameters. I'm not aware of any good reason for the Razor compiler to complain about this.

[SteveSandersonMS]

Scenario that prompted this:

• I'm using gRPC with codegen in a "hosted in ASP.NET Core" app
• The codegen produces client classes in Client and server ones in Server
• In the client, I must set the type access modifier to internal otherwise it conflicts with the ones in Server
• Now the fact that the domain type is internal means it's impossible to pass it as a parameter to another component in the same assembly, which is an absurd restriction
  • I didn't find any satisfactory workaround. I know you could wrap the type in another type, but doing that just to work around this restriction is pretty strange and unfriendly

[SteveSandersonMS]

For more background on why we originally switched from private to public on parameter properties, see #8825.

I don't think the concerns raised there actually apply to the question about whether application code should be allowed to use internal (or even private). Our concerns were about framework components using private and how much it confused all our other infrastructure and tooling (e.g., ref assemblies, docs, metadata analysis).

However I do think there's a separate concern we should think about. Now that it's assumed that component parameters are public, what will people think it means if you declare one as internal? I think people would assume it means "this parameter can only be set when consuming the component within the same assembly (or IVT group)". That's not what it would mean if we just relax BL0004 - the parameter would become usable from any call site in any assembly.

In a case like [Parameter] internal Product EditingProduct { get; set; } where Product is internal it's mostly fine, since other assemblies won't be able to refer to Product anyway. (I'm not 100% clear on whether it's a problem if they somehow obtain one as an object and pass that.)

But in a case like [Parameter] internal string SomeMagicString { get; set; }, it's potentially unexpected that external assemblies can pass this parameter.

Maybe we decide it's not a problem, or maybe we figure out some new analysis rule that complains at the call site if you're not supposed to be able to see the internal APIs of the assembly containing the component.

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.

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.