Remaining pubternal APIs in the shared framework

[davidfowl]

We still have to look at packages but I haven't done that yet: I want to make sure these were intentional and not forgotten. If they were intentional I'd like to understand why they weren't made public APIs

• - Microsoft.AspNetCore.Authentication.Internal (@HaoK @Tratcher, @Pilchie)
• - Microsoft.AspNetCore.Builder.Internal (@Tratcher @davidfowl, @anurse)
• - Microsoft.AspNetCore.DataProtection.Internal (@natemcmaster @blowdart)
• - Microsoft.AspNetCore.DataProtection.Cng.Internal (@blowdart )
• - Microsoft.AspNetCore.Hosting.Internal (@Tratcher @davidfowl @anurse )
• - Microsoft.AspNetCore.Http.Internal (@Tratcher @davidfowl @anurse)
• - Microsoft.AspNetCore.Mvc.Core.Infrastructure (@rynowak @mkArtakMSFT )
• - Microsoft.AspNetCore.Mvc.Razor.Internal (@rynowak @NTaylorMullen @pranavkm @mkArtakMSFT )
• - Microsoft.AspNetCore.Rewrite.Internal (@jkotalik @anurse )
• - Microsoft.AspNetCore.Routing.Internal (@rynowak @JamesNK)
• - Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal (@halter73 @davidfowl @anurse)
• - Microsoft.AspNetCore.Server.Kestrel.Https.Internal (@anurse , @halter73 @Tratcher )
• - Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http (@halter73, @davidfowl @anurse )
• - Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure (@davidfowl, @halter73 , @anurse )

[natemcmaster]

For DataProtection, see #6975 (comment). It's the only context I have on that one.

[pranavkm]

• All of the Razor.Internal ones are runtime compilation specific. We made specific announcements for it.
• The Mvc.Core.Infrastructure is rather unfortunate. It's still there in 3.0: https://github.com/aspnet/AspNetCore/blob/master/src/Mvc/Mvc.Core/src/Infrastructure/IAntiforgeryValidationFailedResult.cs

[HaoK]

For auth, it looks like we only have one RequestPathBaseCookieBuilder class which seems harmless enough to make public along side the rest of the Authentication Core code. Its shared between Cookies, OpenIdConnect and the base RemoteAuthentication classes.

@Tratcher any opposition to just making this regular public? This class hasn't been touched since @natemcmaster added this 2 years ago when he introduced the cookie builder stuff.

[davidfowl]

The Mvc.Core.Infrastructure is rather unfortunate. It's still there in 3.0: https://github.com/aspnet/AspNetCore/blob/master/src/Mvc/Mvc.Core/src/Infrastructure/IAntiforgeryValidationFailedResult.cs

@pranavkm Why not move it out of the internal namespace?

[davidfowl]

For DataProtection, see #6975 (comment). It's the only context I have on that one.

@blowdart besides "leave DataProtection alone", do you know if we can make this type internal now or make it properly public? There are 2 types:

public class DataProtectionBuilder : IDataProtectionBuilder {
         public DataProtectionBuilder(IServiceCollection services);
         public IServiceCollection Services { get; }
     }

This could be public or internal.

public interface IActivator {
    object CreateInstance(Type expectedBaseType, string implementationTypeName);
}

This should be internal.

[blowdart]

Why should it be internal?

@GrabYourPitchforks can you remember why this was written in this way?

[Tratcher]

@HaoK Yes, RequestPathBaseCookieBuilder can be public.

[Tratcher]

For sanity sake, let there only be one breaking change announcement that we add a few comments to.

[davidfowl]

Why should it be internal?

It's a utility interface that's an internal implementation detail that doesn't need to be exposed to external users. We're doing mass clean up of pubternal types in ASP.NET Core 3.0, data protection is part of that clean up.

[davidfowl]

@pranavkm All of the Razor.Internal ones are runtime compilation specific. We made specific announcements for it.

Can we move the code gen helpers to a CompilerServices namespace?

[pranavkm]

Can we move the code gen helpers to a CompilerServices namespace?

Not super sure I follow. Are you talking about CSharpCompiler? For a lot of the others, the actual interface types are still public, as a rule MVC does not expose the actual implementation type.

[davidfowl]

Not super sure I follow. Are you talking about CSharpCompiler? For a lot of the others, the actual interface types are still public, as a rule MVC does not expose the actual implementation type.

No, the types in Razor.Internal, like RazorInject attribute and the other things you said are required for code generation.

[pranavkm]

We decided to leave RazorInject in the pubinternal namespace. We wanted to avoid breaking 2.2 RCLs with generated content. We're treating it as part of our public API surface even though it's in the .Internal namespace.