{"id":7110,"date":"2017-07-14T12:00:08","date_gmt":"2017-07-14T11:00:08","guid":{"rendered":"http:\/\/www.markwilson.co.uk\/blog\/?p=7110"},"modified":"2017-07-13T08:18:30","modified_gmt":"2017-07-13T07:18:30","slug":"introduction-microsoft-net-standard","status":"publish","type":"post","link":"https:\/\/www.markwilson.co.uk\/blog\/2017\/07\/introduction-microsoft-net-standard.htm","title":{"rendered":"Introduction to Microsoft .NET Standard"},"content":{"rendered":"

A few months ago, I was (along with about 70 other rMVPs<\/a>) privileged\u00a0to be on a Skype call with Scott Hanselman<\/a>\u00a0(@shanselman<\/a>) as he gave an overview into Microsoft .NET Core. Some of what was discussed was confidential but the general overview of how .NET Core fits with the full .NET Framework and with Mono\/Xamarin was a great education for a non-developer like me and it seems fine to reproduce it here for the benefit of others.<\/p>\n

This is part 2 of a 2-part series. In part 1, I explained<\/em>\u00a0.NET versions and the lightweight, cross-platform\u00a0<\/em>Microsoft .NET Core SDK. This post moves on to look at standardising\u00a0<\/em>Microsoft .NET.<\/em><\/p>\n

Where does .NET Standard fit in?<\/h3>\n

Hopefully in part 1, I showed\u00a0how .NET Core is a fantastically quick to run set of development tools that can run across platforms but you might also have heard of .NET Standard<\/a>.<\/p>\n

Over the years, the .NET landscape has become pretty complicated (the discussion on versions just scrapes the surface) and we should really think of “.NET” as a big umbrella for marketing purposes with three main instances:<\/p>\n

    \n
  1. Microsoft .NET Framework is really the .NET (Full) Framework – it runs on Windows clients and servers.<\/li>\n
  2. Microsoft .NET Core is for server applications with no UI and is ideally suited to microservices, Docker containers, web apps and more. It runs on Windows, MacOS and multiple Linux distributions.<\/li>\n
  3. Mono<\/a> (led by Xamarin) is an open source cleanroom implementation of .NET – written without access to the code. Its developers looked at the interfaces\/shape and made new versions, which means it has the benefit of running anywhere (e.g. “exotic places” like a Sony Playstation, or on tiny devices).<\/li>\n<\/ol>\n

    That means .NET code can, theoretically run anywhere. Except that the versioning gets in the way… and that’s where .NET Standard fits in.<\/p>\n

    .NET Standard is a target. Not a platform. Not a runtime. It’s an “agreement”.<\/p>\n

    If that’s difficult to understand, here’s the analogy thatScott Hanselman<\/a>\u00a0(@shanselman<\/a>) used in a recent webcast: Android developers don’t\u00a0target an Android OS (e.g. v4.3), they target an API level (e.g. 15). If a new API is released that provides new capabilities, a developer can move to the new API level but it might not work on older devices.<\/p>\n

    Microsoft has something like this in Portable Class Libraries<\/a>, except they are the lowest common denominator – the centre of a Venn diagram. .NET Standard is about running anywhere so that if a developer targets their application to a standard, they can be sure it will run wherever that standard is supported.<\/p>\n

    The .NET Platform Support table<\/a>\u00a0demonstrates this and indicates the\u00a0minimum<\/em>\u00a0version of the platform that’s needed to implement that .NET Standard.<\/p>\n

    \".NET
    .NET Platforms Support table as at July 2017<\/figcaption><\/figure>\n

    For example, if you want to run on .NET Framework 4.5 and .NET Core 1.0, the highest .NET Standard version you can use is .NET Standard 1.1; if you want to run on Windows 8.1 you can’t go above .NET Standard 1.2; etc.\u00a0The higher the version, the more APIs are available and the lower the version, the more platforms implement the standard. Developers target a framework for specific Windows APIs and target a .NET standard for\u00a0portability and flexibility.<\/p>\n

    Resources<\/h3>\n