Runtime: Why there are many unimplemented mthods in the release version?

[akimusume]

I used the System.Security.Policy.Hash.CreateMD5(in System.Security.Permissions) method in my project and found it always returns null. I decompiled it in vs and found it throws null. Then I found its source code in github , it's really returns null.
Why such unimplemented mthods appear in the release version of .net core without any warning?

[msftbot[bot]]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
Notify danmosemsft if you want to be subscribed.

[saucecontrol]

Code Access Security is one of several things documented to be not supported on .NET Core. The API surface was brought in for compatibility purposes, but everything in it is a no-op.

[akimusume]

Thanks。
Then how can I know an specific api is unsupported by a simple way such as xml document, intellisense tips or compile errors instead of reading general-purpose online document?
And what can I use to calcucate hash without third-party library?

[saucecontrol]

If you just want to calculate a hash, you want System.Security.Cryptography. The MD5, or better yet SHA512 or SHA256 classes in there are what you need.

Seems you just stumbled into a weird place in the API. That functionality has been dead for a long time, even on .NET Framework.

[saucecontrol]

Oh, I think I see what happened. That link, without a version on it, goes to the Platform Extensions docs. Platform Extensions are for legacy support code only. The correct link is https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography?view=netcore-3.1

[akimusume]

Thank you for your answer. Then what do you think of the first question? Why not throwing a NotImplementedException and note that "It is unsupported, please use xxx instead. See 'link'" instead of returning null to make the api look normal?

[saucecontrol]

That's not my area of expertise, but I'm sure someone from Microsoft will chime in. My understanding is that CAS was deemed to be meaningless and so a no-op implementation was no harm. It exists purely for compatibility with old .NET Framework software, which frequently made use of the CAS attributes (it was even recommended practice long, long ago). There was a push to fill in some of the old .NET Framework APIs in .NET Core to ease the transition of legacy software. An implementation that throws an exception would have defeated the purpose.

Those APIs are most certainly not something new users should be looking at, and it's unfortunate you stumbled on them when looking for basic hashing support.

[akimusume]

An implementation that throws an exception would have defeated the purpose.

In my opnion, if one legacy software really rely on this api, it can't work properly if the api always returns null. So it's better to throw an exception to expose the problem, at least they can location the propbem quickly.

I didn't search for a appropriate way to get hash. I just typed "Hash" and saw can the intellisense give some advice and it recomended me the System.Security.Policy.Hash😂. I shoud search first.

[krwq]

The recommended way to hash is to use IncrementalHash, i.e. (written by hand, not tested):

using (IncrementalHash hash = IncrementalHash.CreateHash(HashAlgorithmName.MD5)) // or as recommended it's better to use one of the SHA2 family algorithms
{
   hash.AppendData(new byte[] { 1, 2, 3 });
   byte[] yourHash = hash.GetHashAndReset();
}

As for the compat, I'm slightly torn if we should throw PlatformNotSupportedException vs no-op vs just fill useful implementations.

If we're gonna fill any gaps might be worth to gather what actually would be useful to add first

[GrabYourPitchforks]

CAS / Evidence / security policy is one of those things that's in a limbo state. These concepts aren't supported in .NET Core, and when Core was created the intent was for these APIs to fail gracefully. The idea is that existing code might be compiled with references to the CAS infrastructure, and if that existing infrastructure no-ops then the code will usually just work. So throwing exceptions was not desired.

More recently there has been a shift in thinking: we should consider really, truly, _actually_ obsoleting these things so that developers who are relying on them to have a specific behavior aren't surprised when they no-op. See https://github.com/dotnet/runtime/issues/31279 and its linked issues for some further discussion on this point.

[bartonjs]

Then how can I know an specific api is unsupported by a simple way such as xml document, intellisense tips or compile errors instead of reading general-purpose online document?

We have an analyzer which should help: https://docs.microsoft.com/en-us/dotnet/standard/analyzers/portability-analyzer

[bartonjs]

Since the questions have been answered and there hasn't been activity lately, closing the issue.