Standard: What is the definition of supporting a specific .NET Standard version?

[genstein]

The introducing .NET Standard blog entry states:

NET Standard is a set of APIs that all .NET platforms have to implement in order to gain access to the .NET library ecosystem... Optional APIs aren’t part of .NET Standard.

This implies, but does not state, that the implementation has to fulfill the contract of the original API.

The Review board documentation states:

If a library is written in pure IL (for example C#, VB.NET, F# etc.), and targets .NET Standard, then it can run across all current and future .NET platforms with no code changes.

This goal would require that implementations do fulfill the contract of the original API.

However the README states:

.NET Framework 4.6.1 will allow referencing binaries that are compiled against .NET Standard 2.0

And this comment on a closed issue states:

"What will happen when a .NET Standard 2.0-targeted program runs on .NET Framework 4.6.1 which doesn't have all the capabilities? Will it crash?" Yes, the program will throw a MissingMemberException, if you call one of the ~40 members that aren't available there. If that's unhandled, the program will crash.

Let's ignore whether or not that's a Good Thing or not, or whether .NET 4.6.1 will claim to support the standard; I don't have issue with what a particular platform is doing or claiming.

My question is, what is the standard's own definition of support? Say a platform claims support of .NET Standard x.y; how do we evaluate whether it genuinely does? What does support mean, in the standard's view? Can all other platforms supporting x.y take the same approach? What in the standard for x.y prevents a new platform from claiming support for a particular standard version by stubbing out 15,000 methods with NotSupportedExceptions?

Could the .NET Standard, as a document, body or otherwise, take a view as to what qualifies as supporting a specific standard version, and commit that to the standard? It would make sense for that definition of support to be part of the specific standard version.

[danmoseley]

@terrajobst

[weshaggard]

At the end of the day a given platform can claim what they want and throw for all the APIs however doing so will block them from consuming libraries in the .NET ecosystem targeting the standard. The goal of the standard is to try and agree on a common set of APIs that platforms should provide.

The behavior should be as consistent as possible across the different implementations, we are actually planning to provide a set of tests that are built against .NET Standard that platforms can run to try and ensure consistency with the standard. However with that said not all platforms will be able to provide the same behavior or support for all APIs so there will be exceptional cases for certain platforms. Our hope is that those will be minimal and the exceptional case and not the norm.

[21c-HK]

This issue is important and there needs to be detailed information on what exactly is not supported on each platform targeting a specific .NET Standard version. There is no point in having a "Standard" when you cannot be relatively confident that your application is going to run on a "supported" platform without unexpectedly throwing exceptions (after reading the documentation and avoiding non-universal APIs). I am pretty sure that there will be an unofficial "safe Standard" where developers will avoid the APIs that are not really supported on all .NET platforms.

[terrajobst]

Hey @genstein, you're raising an important point and I agree that we should precisely document what it would mean for a .NET platform to implement .NET Standard. First of all, we need this anyway to drive the implementation across the existing .NET platforms. Secondly, it might help new platforms when we need to bring them up, and lastly it can help further the understanding in our community on how .NET Standard actually works. I'll take a crack at it later.

[weshaggard]

We do intend to have some tooling that will help guide developers on which APIs might have issues on certain platforms once platforms start implementing the standard. At this point we don't have all the data or the tooling to make that experience better.

If your familiar with the older PCL world we tried exposing only APIs that worked everywhere and the result was a smaller jagged API surface area that wasn't super useful for folks. Which is why with .NET Standard we are trying to expose a more complete API surface so developers can use it and have a chance to work on the platforms they care about. Yes that will mean some rough edges but our hope is that those edges can be fixed by the individual platforms as opposed us blocking developers from using that API because it might not work on all platforms.

[jarenduan]

Hi everyone. To me it just does not make any sense that a platform claims supporting .net standard on one hand, and throws "not supported" on the other hand.

The required APIs are basically fine, cos' they are expected to behave same on all the supported platforms. I understand the problems mainly focus on optional APIs, such as registry/app domain/emit, and etc., which are OS/runtime specific ones.

I think the underlying question, which is more important, is why developers would use these APIs. A library could use registry to store application settings, or to fetch windows system information. It could use appdomain to create an app domain, or just querying assembly information. I am not familiar with emit, but I think there must be part of it are able/need to cross-platform.

IMHO, we should consider and identify those "underlying meaningful and crossable" requirements, and make .Net Standard an OS/runtime independent specifications. Because if those requirements are supported by the standard, developer wouldn't turn to the OS/runtime specific APIs in most of the time. For instance, if .Net Standard provide a universal app setting APIs, a lot of netstandard developers might not use registry any longer. Well, they might still have to depend on these APIs to do some platform-specific things, however, they are then actually developing a "platform" library instead of a "standard" one, and they'd best to multi-target to work around.

I suggest we don't just focus on covering existing APIs, but try to evolve .Net Standard by abstracting the underlying requirements from the platform specific APIs, and let .Net Standard be more prospective than the existing platforms. A standard should always be a bit ahead of implementations.

[wtgodbe]

@terrajobst what do we want to do here? Do we consider the issue resolved by https://github.com/dotnet/standard/blob/master/docs/faq.md?

[terrajobst]

At this point it's unclear whether we need to do anything. This question in the FAQ answers why throwing is sometimes better.

[genstein]

I completely see the practical rationale, but closing this issue does mean that "this platform supports .NET Standard X.Y" and "this application runs on platform supporting .NET Standard X.Y" are empty (read: marketing) statements, rather than technical or reliable ones, since "support" is undefined.

[terrajobst]

are empty (read: marketing) statements

That's not true. The promise is that .NET Standard centralizes which APIs platforms actually offer. So compilers and other systems can rely on the API being there. This is fairly important and unblocks a lot of tooling that wouldn't be possible with marketing statements alone.

The behavior of the APIs isn't undefined either -- but they are platform defined. The reason I'm closing this issue is that we're moving towards implementation unification. This isn't like Java where there actually exist two entirely different implementations of the stack. We're planning on unifying .NET Core and Mono/Xamarin in the .NET 5 time frame. As such, I don't believe there is sufficient reason why we'd need a formal definition of .NET Standard compliance outside of the API set itself. We've talked about having a test suite that implementations would have to pass, but building something like this is fairly costly. And the benefit for the consumer would be low, given that the behavior will converge anyway.

[genstein]

.NET Standard centralizes which APIs platforms actually offer
The behavior of the APIs ... are platform defined

These two points clear it up for me, thanks. I had genuinely thought when I opened this issue that .NET Standard had been intended to imply (and later, mandate) a degree of behavioural compliance or consistency (or similar) across platforms; if .NET Standard "just" means API existence and the associated benefits around compilation, likely time savings in portability, etc. but without any guarantees whatsoever on functionality, that's my mistake and nice and simple.