Make types in Microsoft.AspNetCore.DataProtection.KeyManagement.Internal internal #54707
Conversation
…nal internal IInternalXmlKeyManager and ICacheableKeyRingProvider are explicitly test hooks and the other types are implementation details. They aren't included in our public API documentation since they aren't intended for external consumption.
ghost
added
the
|
If CI is green, I'll make an API proposal. |
|
@GrabYourPitchforks might remember why they weren't internal in the first place. I don't think it was a lack of IVT because they mostly have internal members, but maybe there was a partner or automated process that needed access? |
dotnet-policy-service
bot
added
the
pending-ci-rerun
|
Historical context: in early aspnetcore, there was a design philosophy that all types should be public, so that people could hack around any limitations they might encounter with the official API. This, apparently, did not extend to members, so some of these public types aren't meaningfully usable (either because they have no public members or because they are passed to other types via internal members). While we now accept that some types should be internal, we're not willing to hide the already public ones because we don't want to cause binary breaks for existing consumers. |
IInternalXmlKeyManager and ICacheableKeyRingProvider are explicitly test hooks and the other types are implementation details. They aren't included in our public API documentation since they aren't intended for external consumption.
Fixes #54712