runtime: HashAlgorithm.Create throws PNSE on .NET Core 2

It seems that we missed that:

• HashAlgorithm
• HMAC
• KeyedHashAlgorithm
• SymmetricAlgorithm
• AsymmetricAlgorithm

live inside System.Security.Cryptography.Primitives while CryptoConfig (which is needed to implement Create(string)) lives inside System.Security.Cryptography.Algorithms which depends on System.Security.Cryptography.Primitives. Fixing this would create dependency problem.

Given that we have decided NOT to add this back for now as there is not much requests for this and the workaround is straightforward.

For anyone interested in adding this back please comment and upvote this issue. Closing for now.

@krwq to be clear, I’m not referring to HashAlgorithm.Create(), I specifically need HashAlgorithm.Create(string), which takes in the name of the algorithm to create. No defaults. The workaround is just silly IMO, that it’d cause bunches of existing code to break at runtime.

Reopening due to activity on https://github.com/dotnet/standard/issues/530.

This needs fixing in more places:

Searching 11736 files for "Create\(string.*\n.*{.*\n.*PlatformNot" (regex)

C:\git\corefx\src\System.Security.Cryptography.Primitives\src\System\Security\Cryptography\AsymmetricAlgorithm.cs:
   19:         public static AsymmetricAlgorithm Create(string algName)
   20:         {
   21:             throw new PlatformNotSupportedException();

C:\git\corefx\src\System.Security.Cryptography.Primitives\src\System\Security\Cryptography\HashAlgorithm.cs:
   23:         public static HashAlgorithm Create(string hashName)
   24:         {
   25:             throw new PlatformNotSupportedException();

C:\git\corefx\src\System.Security.Cryptography.Primitives\src\System\Security\Cryptography\HMAC.cs:
   31:         public static new HMAC Create(string algorithmName)
   32:         {
   33:             throw new PlatformNotSupportedException();

C:\git\corefx\src\System.Security.Cryptography.Primitives\src\System\Security\Cryptography\KeyedHashAlgorithm.cs:
   16:         public static new KeyedHashAlgorithm Create(string algName)
   17:         {
   18:             throw new PlatformNotSupportedException();

C:\git\corefx\src\System.Security.Cryptography.Primitives\src\System\Security\Cryptography\SymmetricAlgorithm.cs:
   20:         public static SymmetricAlgorithm Create(string algName)
   21:         {
   22:             throw new PlatformNotSupportedException();

Lets make sure we leave this in the 2.0.0 milestone so we don’t lose track of it for the first update.

There are always going to be bugs in the platform implementations of .NET Standard that may require workarounds.

Yes, as long as you want to behave well on 2.0.0 you will have to use the workaround. The lifespan of 2.0.0 should be fairly short as support for it will die off quickly once we ship a 2.0.1 which I expect will only be a month or two out. Apps will automatically roll forward to it, all the download links will be updated, and servicing releases will have security fixes in them where we will strongly encourage people to get the latest.

@Petermarcu as a library author, how do I know where the fix is and how to set baseline requirements? I can target netstandard2.0, but then what? There’s no way for me to force that it needs netcoreapp2.0.1 on that platform?

Basically, the question/issue is around how long should a workaround stay in place for? (it’s a more general topic), but doing feature-detection and then having both code-paths seems really redundant (for this).