Rick Strahl's Web Log

Wind, waves, code and everything in between...
ASP.NET • C# • HTML5 • JavaScript • AngularJs
Contact   •   Articles   •   Products   •   Support   •   Search
Ad-free experience sponsored by:
ASPOSE - the market leader of .NET and Java APIs for file formats – natively work with DOCX, XLSX, PPT, PDF, images and more

.NET Standard 2.0 - Making Sense of .NET Again


At last week's .NET Connect event and two-weeks ago at the MVP Summit we got to hear about Microsoft's vision for .NET going forward. A lot of people - myself included - in recent years have wondered what the future of .NET is.

A key component in this process is .NET Standard...

It's taken Microsoft a few years of floundering and unclear messaging about the future of .NET, but it seems Microsoft is finally nailing the message for .NET going forward and .NET Standard, with its common API specification, is a huge part in making sure that the same base library functionality of .NET is available on all .NET platforms in the future.

In this post I look at what .NET Standard is, how it works and what some of the surrounding issues, impacts and benefits are for the .NET Eco system.

What is .NET Standard?

Here's my definition of what .NET Standard is:

.NET Standard is a specification, not an implementation

.NET Standard describes what a specific implementation like .NET Core, Mono, Xamarin or .NET 4.6 has to implement - at minimum - in terms of API surface in order to be compliant with a given version of .NET Standard.

The actual implementations of today's shipped .NET Standard 1.6 are .NET Core, the full .NET Framework and Mono. The current version of the standard is .NET Standard 1.6 which shipped when .NET Core 1.0 was released. Implementations can implement additional features beyond .NET Standard in their base libraries but at minimum each implementation has to implement the standard APIs of the Standard even if specific APIs end up with NotSupportedExceptions.

.NET Core as a Reference Implementation

As you might expect the API surface of .NET Standard 1.6 coincides pretty closely with the API surface of .NET Core 1.0.x and I expect that .NET Core 1.2 (or whatever the next version will be named) is likely to match very closely to what .NET Standard 2.0 specifies. In that sense it's almost like .NET Core is the reference implementation for .NET Standard at the moment. That may change in the future, but for now that's certainly holding true.

Since .NET Standard is based on full framework APIs, full framework is pretty much compatible with .NET Standard without changes, although there are a few small variations that are addressed by small update releases in .NET 4.6.1 and 4.6.2 etc.

.NET Standard corresponds to the BCL

If you're looking at .NET Standard in terms of the full version of .NET you've used for the last 15+ years, you can think of .NET Standard roughly representing the feature set of the BCL. This is the core .NET library of what used to live exclusively in mscorlib.dll and the various system dlls.

This roughly corresponds to the core .NET Base Class Library (BCL) and includes the basic type system, the runtime loading and querying operations, network and file IO, and some additional APIs like System.Data. With .NET going cross platform it's important to know that this subset has to be platform agnostic and not expect to run on any specific Operating System.

Here's a rough idea of what you can expect to see in .NET Standard 2.0:

The BCL always has been about core operating system, runtime and language services, so this OS agnostic requirement shouldn't be a huge issue. Much of the porting work that goes into moving full framework libraries to .NET Core deals with making sure that functionality works across platforms. There are lots of small issues that can trip up things like the difference in path separators between Operating Systems and the way that operating system services like threads/processes are implemented on various platforms.

Application Frameworks are not part of .NET Standard

The key thing to remember is that if you compare the full .NET Framework to what will be in .NET Standard you are only getting what is in the BCL, not what we know as the Framework Class Library (FCL). Full framework as we know it today has additional features piled on top with the FCL Libraries that sit on top of the BCL. Frameworks in this case are application platforms like ASP.NET (System.Web and OWin based), WinForms, WPF, WCF etc. For .NET Core ASP.NET 5 is an Application Framework that lives ontop of .NET Standard. These libraries are not part of .NET Standard, but they are implemented on top of it.

.NET Standard Versions

The current shipped version of .NET Standard is 1.6 and it roughly coincides with the feature set of .NET Core 1.0/1.1. The feature set in this version is fairly limited and significantly less featured than the full version of .NET and that has caused a lot grumbling in the community. Some of the missing APIs seem really arbitrary often removing overloads or extended features that just end up creating refactoring or code bracketing work.

Because many APIs and features are missing, it's been difficult to port existing libraries to .NET Core/.NET Standard as many basic features are missing. While the missing APIs can often be worked around, it's a not a trivial task to hunt down all the missing APIs in a large applications and adjust code using code bracketing (#if/#else blocks) to potentially run both in .NET Standard and full Framework applications.

Worse - knowing that .NET Standard 2.0 is on the horizon, it's very likely that those workarounds and adjustments won't be necessary in the future, so it's hard to justify putting in the effort to port now. It's no surprise that many library authors - including myself - are holding off and waiting for more API surface to port libraries to .NET Standard/.NET Core.

.NET Standard 2.0 more than doubles the API surface over v1.6, and some major missing or severely decimated APIs like Reflection and System.Data get back their original mojo. According to Microsoft's numbers .NET Standard provides a 149% increase in API surface over .NET Standard 1.6 and climbing which is quite significant! Life will be much easier.

In the end the goal is this:

Uniting .NET Implementations

.NET Standard provides a common base .NET Interface to all platforms that implement it so that no matter which version of .NET you use you'll always see at least the same base feature set.

and you should be able to use the same .NET Standard interface on any of these .NET platforms:

What about PCLs?

.NET Portable Class Libraries (PCL) had a similar goal as .NET Standard but approached this problem from a different angle. Where .NET Standard uses a fixed set up APIs to describe what comprises a .NET Standard Compliant implementation, PCLs used a union of all the common APIs that included platforms support. When building a PCL you 'check off' the platforms you want to compile the PCL for and the compiler figures out the common APIs that are supported. Effectively, the more platforms you support with a PCL the less API surface there is as each platform actually takes away features.

.NET Standard is different. It's a fixed specification - there are a set number of APIs that have to be supported by the implementation, so nothing is taken away by adding platforms. You may see unimplemented APIs (NotSupportedException) in rare cases, but the API will be there.

This is a much better approach by far: Rather than removing non-universal APIs to shrink the common API surface, the API surface stays the same. On any given platform you can then selectively disable support for features that are not implement, but other platforms that do support it can use it fine. This makes the compiler happy as it sees the same API surface on all platforms and gives the control to you as the developer to decide what features of the API you call - or don't call on specific platforms.

.NET Standard gives developers a common .NET baseline that they can expect to use regardless which platform they write for.

Posted in .NET  ASP.NET Core  .NET Core  

The Voices of Reason


 

Angus McIntyre
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

I'm still not sure what .Net Standard is meant to achieve. Is it intended as a slicker development pipeline for PCLs?


Kevin
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Oh No, this sentence makes me cringe.

"Looks like the Visual Studio 2017 release will take us back to the bad old days of where a new version of Visual Studio is required to go along with a specific version of .NET development "


Rick Strahl
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

@Angus - it's supposed to provide a baseline that all .NET implementations on whatever platform you use. The idea is that you have the same set of features everywhere and if you build a library that targets .NET Standard it will run on any of the platforms that implement it. PCL was an interception of features - the more platforms you supported the less features you got. .NET Standard will provide a fixed base feature set.


Andrea Angella
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Very nice post Rick. I didn't know about the TypeForwardedToAttribute that apparently was there since NET 2. I am glad I didn't start putting my hands on .NET Core yet. I am waiting for the tooling to be ready (VS 2017 RTM?) and the official release of .NET Standard 2.


Andrei Rînea
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

I almost read "Making .NET great again" 😃))


Richard
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

.NET Standard to me is analogous to classes and interfaces. .NET Standard 1.0/1.1/2.0 are interfaces, which are implemented by .NET Core Windows/.NET Core Linux/.NET Full Framework/Mono/etc x the various version numbers of those frameworks.


Thomas Hansen
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Could you, or anybody else for that matter, answer what happens to WebForms in the future ...? Thanks for a nice writeup though, as usual ... 😃

PS! There's a "foward" up there in the beginning of your blog. I assume you meant "forward" ...


Jeff P.
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Very accurate state of the union, especially the tooling comments. I've ported one of my apps without too much friction, other than the breakage from RC1 to 2 to RTM.


Rick Strahl
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

@Andrei - re: Making .NET Great Again. I thought about it, but given the political mood probably not the best idea :-)

@Thomas - WebForms will continue to work on full framework (ie. .NET 4.6.x etc) and according to what I heard from the ASP.NET teams will continue to get new features and enhancements that trickle down from the other technologies. It's not dead, but it won't run on .NET Core - it'll always be a full framework technology, which isn't a problem since that technology will continue forward in parallel with the .NET Core.


Hannes Preishuber
November 23, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Webforms (and Winforms) have a goal which differs from .net Standard. From my view .net Standard is a clean and lean approach to target any device

Webforms is a thing for a (big) server, so old .NET and big dotnet is not a issue. Especially as Webforms is often used for intranet solutions and less for kind of websites.

-Hannes


Laurent Kempé
November 24, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Great post Rick! It reminds me a discussion about .NET with my brother a couple weeks ago, in which we also believe that we are at a turning point for .NET At the moment the future looks promising!


Lee Timmins
November 24, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Thanks Rick. Great read and cleared up a few things. From my understanding I see .NET Standard as an abstractions model where .NET Core, .NET Framework and Xamarin are implementations.


Alex Sarafian
November 24, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

I also don't understand clearly what it is. I understand where they want to get to and it is a positive step but I think there are complicating things with too many terms.

In my opinion they should have made this very clear statement. We are building .NET cross platform from the beginning. We have ported ... and we are porting .....

This is what they are doing really but they are trying so hocus pocus to make it look as more seem less.

The parts that interest the business app I'm working on are System.ServiceModel and System.Identity and I don't believe they are supported or going to be supported in the near future although they are System assemblies. Second in priority I would like to have the System.WinForms but I don't believe they would ever port that functionality either.

Thanks for the post


Rick Strahl
November 24, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

@Alex - if you want to build applications with those technologies (ie. WinForms/WCF) then you can stick with .NET Full framework. I'm pretty sure WinForms will never be ported, although there's Mono that has an implementation of it that can run on Mac and Linux. I doubt Microsoft will make a crack at providing a true cross platform UI framework in the near future, but who knows.

.NET Standard is what lays the ground work to let Microsoft and Third Parties innovate on top of the platform more easily for cross platform environments and that's the key of what this push entails I think. What you're looking for is much higher level at the Framework level.


Alex
November 24, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Good article, which to me represents the current thoughts of most .net devs.

One question though why didn't they name it the .Net Standard Interface? I think most devs would have then easily understood what MSFT were trying to do.


Thomas Burkhart
November 25, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Hi Rick,

very nice post!

Brings it to the point and I hope netstandard 2.0 will be out soon. Me too am waiting for it before switching my projects.

Cheers Thomas

P.S: What's that stick on your back on the headers surfing picture


Chris
November 25, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Great post Rick, as always. We looked at ASP.NET Core a while back but it was apparent that the inablity to use the features provided by System.Web as well as features missing in Entity Framework 7 meant that we held off creating / updating applications to use it. Pretty much all the stuff we write is Web Forms Websites in VB.NET using LINQ to SQL (eek!). So the ability to run cross platform is not really important to us. As you say the API coverage will improve with .NET Standard 2.0 so maybe we can look at it again then. I suspect the driver for this will be when Visual Studio 2017 is RTM. Even then the Developers are still going to need a pretty solid business case to convince our Directors that this is the way that we should be writing Web Applications going forward.


Fred Peters
November 26, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Great report, and you covered the state of ASP.Net Core with this sentence "Currently you have to know way too much about the innards of the technology to be productive."


SPEC India
November 29, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Indeed a great one Rick. I too agree with Fred. This post cleared some doubts of mine and going to share this with my team.


Simon Timms
November 30, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Great article as always, Rick. I spoke to some MS devs at summit who didn't believe the new project system would be available in vs2015. There are, as you might imagine some significant changes to the project system in visual studio required which don't make sense to move backwards.


Rick Strahl
November 30, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

@Simon - yeah I know that that's the case, still it's a bummer that that's the case because it does mean that many people will end up with side by side versions of Visual Studio again which is a curse. But as long as it works in VS2017 *and* 2017 provides backwards compatibility at least for all but .NET Core (original) projects I suppose its all good. I just know that I still have customers that are stuck on VS2010 due to some build system issues that never allowed them to upgrade. Heck I was like that with VS2010 due to some C++ compiler issues that weren't resolved until SP2 of VS2015. I'm hoping that won't happen again.


Joel Leach
December 02, 2016

# re: .NET Standard 2.0 - Making Sense of .NET Again

Hi Rick. Another great article. It'll be nice when this stuff comes along. I'm in that awkward place of working on a new app with the current versions of .NET/ASP.NET, because the new tech isn't quite ready for prime time.

Something you might find of interest is that some COM interop APIs are currently included in .NET Standard 2.0, even though COM will not be implemented on .NET Core for Windows. I wrote about that (http://weblogs.foxite.com/joel_leach/2016/10/19/com-interop-with-net-core/), and there is some ongoing discussion on GitHub (https://github.com/dotnet/standard/issues/55).


Damon Allison
January 17, 2017

# re: .NET Standard 2.0 - Making Sense of .NET Again

Great article. It gave me a "real world" state of the .NET Core platform. From my limited usage of .NET Core, I completely agree with Rick. The current state of tooling, standards, direction is confusing at best. Microsoft desperately needs to simplify their messaging to developers.


Tim
March 27, 2017

# re: .NET Standard 2.0 - Making Sense of .NET Again

Thank you for this good summary! Did you by any chance find a human-readable overview which shows which .netstandard-Version features which APIs? Oh, and it's "Immo Landwerth", with an 'e', not an 'i'.


Edward
April 21, 2017

# re: .NET Standard 2.0 - Making Sense of .NET Again

I think that all of this is an utter mess, and that as a developer I do not feel at all confident I should move any of my development (which thus far has been largely ASP.NET on the full .NET Framework on Windows) across to .NET Core or anything else, until all of this has been brought to some level of stability.

In the last 5-10 years, development on Windows has gone from a relatively simple concept with one .NET Framework to build purely Windows client/server apps to today's bewildering array of APIs and "technologies" introduced with Windows 8.1 and 10 and competing mobile platforms.

But what's the incentive to learn any of it? For client-side windowed apps, I could understand learning UWP on Windows 10, but no-one's buying Windows 10 Phones so why bother? Windows 10 tablets still run the full version of Windows so why bother with the Modern UI? Windows 8 and its related phones weren't a hit. Silverlight is dead, and it's relation WPF wasn't adopted as much as MS hoped. Might as well just stick with WinForms! And, as for ASP.NET apps, Windows servers work pretty well and the full .NET Framework is stable and well documented.

Now they're trying to integrate Xamarin and reflection of foreign iOS and Android APIs into the system and bringing on Linux and Mac.

Visual Studio and its ecosystem is becoming ever more saddled and cluttered with the technological debt and I feel its becoming unmanageable.

I do feel that .NET did need to go cross platform - that I agree with. But couldn't there have been a better way?

I honestly do not feel there's enough time in the day anymore to keep up with it all. I feel so sorry for new developers entering this world.

Over many years I already made the transition from VB.NET to C# and from WebForms to MVC. Now it feels I'm being asked to relearn everything all over again. When is this going to stop?


Jon
May 02, 2017

# re: .NET Standard 2.0 - Making Sense of .NET Again

it will stop, when you retire. That's the wonder of doing what we do.


Ken
May 04, 2017

# re: .NET Standard 2.0 - Making Sense of .NET Again

I've read about Net Standard for at least a year now, and waited for VS 2017 to come out. Now that it is, I've studied what VS 2017 does in order to understand what Net Standard really is. Unfortunately, I still do not understand why everyone keeps saying that Net Standard is not an implementation, when everything I see in VS 2017 says Net Standard is an implementation. As someone wisely said, "Don't tell me [Microsoft] what you believe in. I'll observe how you behave and I will make my own determination."

Aside, I can accept Net Standard may be also a standard, but what's listed at https://github.com/dotnet/standard/blob/master/docs/versions/netstandard1.6_ref.md is a terrible definition. It contains no semantics, so what one framework would do might be completely different in another framework. Maybe I'm too old school.

So, when I create a Net Standard class library in VS 2017, I can compile it, link to it, and run the code. I can link to the Net Standard DLL from a Net Core app, or a Net Framework app. (See https://github.com/kaby76/NetStandardCoreFramworkExamples for every permutation of interoperability.) I can Dotpeek the Net Standard DLL and see code. If I look at a csproj file for a freshly generated Net Standard class library from VS 2017, it contains only a reference to "netstandard1.4". The csproj file might look like this:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard1.4</TargetFramework>
  </PropertyGroup>

</Project>

I can change this to a multi-target framework with the addition of other frameworks:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFrameworks>netstandard1.6;netcoreapp1.1</TargetFrameworks>
  </PropertyGroup>

</Project>

and see, when built, there are two DLL's generated, one for Net Core, another for Net Standard.

So, if Net Standard is just a standard, and not an implementation, why is there a distinct target with code generated when I build a Net Standard library?

So, what I deduce is that Net Stardard is an implementation. It may not be important, and it all works well, but what people keep saying does not make sense.


Rick Strahl
August 31, 2017

# re: .NET Standard 2.0 - Making Sense of .NET Again

@Ken - When you create a Package that conforms to .NET Standard, you're creating a package that follows the .NET Standard specification. IOW the DLL you create supports only the features available in .NET Standard, plus any additional packages you add. The code you write is 'physically there' of course, but what it's 'binding' to is .NET standard of whatever implementation you are working with that supports that version of .NET Standard.

Anybody who consumes your package now is assured that the package can run under any .NET implementation (ie. .NET Core, full framework, Mono, UWP, etc.) that support that specific version of .NET Standard that you bound to when you built your package.

IOW - you create a specific implementation, but by targeting .NET Standard you are saying "this package is supported on any platform that supports this version of .NET Standard that I bound to".


Jose
September 22, 2017

# re: .NET Standard 2.0 - Making Sense of .NET Again

I agree with @Edward saying .Net Core has been a complete mess. Why can't MS just take their time to build one platform that is just stable and hide all these implementation details? Why should I care about BCL, FCL and a whole bunch of other concepts when all I want is run an app? I don't have to learn any of that when running Java...

 

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2017