CODEWITHSUNDEEP
.netxmlcryptography.net-standard-2.0system.security
Valo
Valo

Reputation: 2048

Why is System.Security.Cryptography.Xml not part of .NET Standard 2.0?

I am a little confused by the fact that almost all types from the namespace System.Security.Cryptography are part of .NET Standard 2.0, but for System.Security.Cryptography.Xml one needs to take a dependency on the extension package by the same name.

Can someone please explain the difficulty here? If the problem was simply not enough people and time, are there any plans for including it in the next versions of .NET Standard?

Upvotes: 2

Views: 2906

Answers (1)

bartonjs
bartonjs

Reputation: 33098

I get the impression that you think that things go into netstandard if they "can", but in reality it's more like they go into netstandard if they "have to".

While this isn't the actual process, a good model is:

  • Rule 0: If the type is mentioned in the ECMA-335 specification, it belongs in netstandard.
    • These types have special interaction with their runtime (clr.dll, coreclr.dll, libcoreclr.so, etc) and thus cannot sensibly be defined via a NuGet package.
  • Rule 1: If a "foundational" type makes sense in (almost?) all operating environments, but is best provided/powered by system libraries, it probably belongs in netstandard (because it's hard to deliver effectively via NuGet).
    • All of the cryptographic algorithm implementations are in this bucket
    • Networking, too
    • Globalization, too
  • Rule 2: If a type is needed by a type already in netstandard, it needs to be in netstandard.
    • Cryptography base classes
    • Stream
    • Okay, pretty much all of netstandard
    • As an evolution example: Current proposed changes for netstandard3.0 include defining the (ReadOnly)Span and (ReadOnly)Memory-based methods that .NET Core added onto existing netstandard types, which means that (ReadOnly)Span and (ReadOnly)Memory will have to go from being "on netstandard" to "in netstandard".

Things that are defined in netstandard require a compatible implementation to define all of the things in it (though "throw new PlatformNotSupportedException();" is a legal implementation of anything). So .NET Framework, .NET Core, Mono, Xamarin, Unity (and any others I can't think of) all need to define a thing. Sometimes the code is shared between these runtimes, but each one carries its own functional implementation; and fixing a bug in one of them requires fixing a bug in all 5+ (or, at least, releasing an update to all 5+).

On the other hand, when functionality can be delivered purely in terms of things already in netstandard, those things are well suited to being hosted on NuGet, and the same DLL can be loaded into all 5+ runtimes and work correctly. When a bug is fixed, it gets fixed everywhere1,2. Much goodness is had by all. These libraries use the Target Framework Moniker (TFM) of a netstandard version, and then they effectively extend netstandard. The only drawback is that consumers need to explicitly add the package reference to build. System.Security.Cryptography.Xml and System.Security.Cryptography.Pkcs are both in this bucket.

1. Types that were already in .NET Framework (or Xamarin, etc) still have to be independently fixed in that runtime, because the NuGet package says to ignore its contents and use the existing implementation on those platforms.

2. For .NET Core, when an assembly is needed as an implementation detail of the runtime it gets included in Microsoft.NETCore.App, and the NuGet package says to ignore its contents and use the existing implementation on that platform, meaning that the bug gets fixed once, but has to be released as both an update to .NET Core and as a NuGet package.

Upvotes: 3

Related Questions