Essentials/IncrementalHashAdapter.cs is public in ktsu.Essentials, the package documented as interfaces-only. It is a thin wrapper over System.Security.Cryptography.IncrementalHash, and it is public solely so the five cryptographic hash provider packages can share one copy.
This is time-sensitive: it has not shipped yet. Once released, making it internal is a breaking change requiring a major version.
The alternative that exists
The same PR solves the identical problem the other way for the non-cryptographic providers. Shared/NonCryptoIncrementalHash.cs is internal and linked into each of six provider projects with <Compile Include>, so one source file compiles into each assembly without exposing anything.
That approach was mandatory there, because a shared NonCryptographicHashAlgorithm adapter living in ktsu.Essentials would have forced a System.IO.Hashing package dependency onto every consumer of the interfaces package. System.Security.Cryptography is in-box on all six target frameworks, so no such pressure applied to the cryptographic adapter — hence the two adapters ended up asymmetric.
The case for leaving it public
PersistenceProviderUtilities sets the precedent: a public static class in ktsu.Essentials shared across the persistence provider packages.- A third party writing their own
IHashProvider over a System.Security.Cryptography algorithm can reuse it instead of reimplementing the adapter. That is a real, if modest, benefit.
The case for making it internal + linked
- Symmetry with
NonCryptoIncrementalHash — two adapters solving the same problem two different ways is a thing future maintainers have to explain.
- A smaller permanent public surface on a package whose selling point is that it contains interfaces.
No action is required if the current shape is deliberate. Filing it so the choice is made consciously while it is still free.
Context: #6, #9.
Essentials/IncrementalHashAdapter.csispublicinktsu.Essentials, the package documented as interfaces-only. It is a thin wrapper overSystem.Security.Cryptography.IncrementalHash, and it is public solely so the five cryptographic hash provider packages can share one copy.This is time-sensitive: it has not shipped yet. Once released, making it internal is a breaking change requiring a major version.
The alternative that exists
The same PR solves the identical problem the other way for the non-cryptographic providers.
Shared/NonCryptoIncrementalHash.csisinternaland linked into each of six provider projects with<Compile Include>, so one source file compiles into each assembly without exposing anything.That approach was mandatory there, because a shared
NonCryptographicHashAlgorithmadapter living inktsu.Essentialswould have forced aSystem.IO.Hashingpackage dependency onto every consumer of the interfaces package.System.Security.Cryptographyis in-box on all six target frameworks, so no such pressure applied to the cryptographic adapter — hence the two adapters ended up asymmetric.The case for leaving it public
PersistenceProviderUtilitiessets the precedent: apublic static classinktsu.Essentialsshared across the persistence provider packages.IHashProviderover aSystem.Security.Cryptographyalgorithm can reuse it instead of reimplementing the adapter. That is a real, if modest, benefit.The case for making it internal + linked
NonCryptoIncrementalHash— two adapters solving the same problem two different ways is a thing future maintainers have to explain.No action is required if the current shape is deliberate. Filing it so the choice is made consciously while it is still free.
Context: #6, #9.