What is the difference between .NET Core and .NET Standard Class Library project types?

570

In Visual Studio, there are at least 3 different types of class library you can create:

• Class Library (.NET Framework)


• Class Library (.NET Standard)


• Class Library (.NET Core)

While the first is what we've been using for years, a major point of confusion I've been having is when to use the .NET Standard and .NET Core class library types. I've been bitten by this recently when attempting to multi-target different framework versions, and creating a unit test project.

So, what is the difference between Class Library (.NET Standard) and Class Library (.NET Core), why do both exist, and when should we use one over the other?

.net .net-core class-library .net-standard

share|improve this question

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  You missed one: Class Library (Portable). Core == framework, .NET Standard == portable.
  
  – Hans Passant
  Mar 21 '17 at 22:41
  
  
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  There was one from Xamarin too, but these other ones don't add any value to the question :)
  
  – Gigi
  Mar 21 '17 at 22:42
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Well, they do. The core idea is the they gave up on the portable approach, it suffered too heavily from the n! problem with way too many profiles. So now you've got 7 standards to choose from. Most are not actually portable right now :) .NETCore is not done by a long shot, probably takes another two years at the clip they are going.
  
  – Hans Passant
  Mar 21 '17 at 22:47
  
  
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  OP said "at least 3 different types". The post was accurate.
  
  – Dan Friedman
  Sep 19 '17 at 20:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  and also there is Universal Windows
  
  – doganak
  Feb 20 '18 at 12:06
  

  
  
  
  

 | 
show 3 more comments

570

In Visual Studio, there are at least 3 different types of class library you can create:

• Class Library (.NET Framework)


• Class Library (.NET Standard)


• Class Library (.NET Core)

While the first is what we've been using for years, a major point of confusion I've been having is when to use the .NET Standard and .NET Core class library types. I've been bitten by this recently when attempting to multi-target different framework versions, and creating a unit test project.

So, what is the difference between Class Library (.NET Standard) and Class Library (.NET Core), why do both exist, and when should we use one over the other?

.net .net-core class-library .net-standard

share|improve this question

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  You missed one: Class Library (Portable). Core == framework, .NET Standard == portable.
  
  – Hans Passant
  Mar 21 '17 at 22:41
  
  
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  There was one from Xamarin too, but these other ones don't add any value to the question :)
  
  – Gigi
  Mar 21 '17 at 22:42
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Well, they do. The core idea is the they gave up on the portable approach, it suffered too heavily from the n! problem with way too many profiles. So now you've got 7 standards to choose from. Most are not actually portable right now :) .NETCore is not done by a long shot, probably takes another two years at the clip they are going.
  
  – Hans Passant
  Mar 21 '17 at 22:47
  
  
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  OP said "at least 3 different types". The post was accurate.
  
  – Dan Friedman
  Sep 19 '17 at 20:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  and also there is Universal Windows
  
  – doganak
  Feb 20 '18 at 12:06
  

  
  
  
  

 | 
show 3 more comments

570

570

570

167

In Visual Studio, there are at least 3 different types of class library you can create:

• Class Library (.NET Framework)


• Class Library (.NET Standard)


• Class Library (.NET Core)

While the first is what we've been using for years, a major point of confusion I've been having is when to use the .NET Standard and .NET Core class library types. I've been bitten by this recently when attempting to multi-target different framework versions, and creating a unit test project.

So, what is the difference between Class Library (.NET Standard) and Class Library (.NET Core), why do both exist, and when should we use one over the other?

.net .net-core class-library .net-standard

share|improve this question

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

In Visual Studio, there are at least 3 different types of class library you can create:

• Class Library (.NET Framework)


• Class Library (.NET Standard)


• Class Library (.NET Core)

While the first is what we've been using for years, a major point of confusion I've been having is when to use the .NET Standard and .NET Core class library types. I've been bitten by this recently when attempting to multi-target different framework versions, and creating a unit test project.

So, what is the difference between Class Library (.NET Standard) and Class Library (.NET Core), why do both exist, and when should we use one over the other?

.net .net-core class-library .net-standard

.net .net-core class-library .net-standard

share|improve this question

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

share|improve this question

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

share|improve this question

share|improve this question

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

edited Dec 25 '18 at 11:57

Mark Amery

63.4k31253302

63.4k31253302

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

asked Mar 21 '17 at 22:34

GigiGigi

10.9k1256134

10.9k1256134

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  You missed one: Class Library (Portable). Core == framework, .NET Standard == portable.
  
  – Hans Passant
  Mar 21 '17 at 22:41
  
  
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  There was one from Xamarin too, but these other ones don't add any value to the question :)
  
  – Gigi
  Mar 21 '17 at 22:42
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Well, they do. The core idea is the they gave up on the portable approach, it suffered too heavily from the n! problem with way too many profiles. So now you've got 7 standards to choose from. Most are not actually portable right now :) .NETCore is not done by a long shot, probably takes another two years at the clip they are going.
  
  – Hans Passant
  Mar 21 '17 at 22:47
  
  
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  OP said "at least 3 different types". The post was accurate.
  
  – Dan Friedman
  Sep 19 '17 at 20:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  and also there is Universal Windows
  
  – doganak
  Feb 20 '18 at 12:06
  

  
  
  
  

 | 
show 3 more comments

• 
  
  
  

  
  9
  

  
  
  
  
  
  

  
  
  You missed one: Class Library (Portable). Core == framework, .NET Standard == portable.
  
  – Hans Passant
  Mar 21 '17 at 22:41
  
  
  

  
  
  
  


• 
  
  
  

  
  4
  

  
  
  
  
  
  

  
  
  There was one from Xamarin too, but these other ones don't add any value to the question :)
  
  – Gigi
  Mar 21 '17 at 22:42
  

  
  
  
  


• 
  
  
  

  
  7
  

  
  
  
  
  
  

  
  
  Well, they do. The core idea is the they gave up on the portable approach, it suffered too heavily from the n! problem with way too many profiles. So now you've got 7 standards to choose from. Most are not actually portable right now :) .NETCore is not done by a long shot, probably takes another two years at the clip they are going.
  
  – Hans Passant
  Mar 21 '17 at 22:47
  
  
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  OP said "at least 3 different types". The post was accurate.
  
  – Dan Friedman
  Sep 19 '17 at 20:49
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  and also there is Universal Windows
  
  – doganak
  Feb 20 '18 at 12:06
  

  
  
  
  

9

9

You missed one: Class Library (Portable). Core == framework, .NET Standard == portable.

– Hans Passant
Mar 21 '17 at 22:41

You missed one: Class Library (Portable). Core == framework, .NET Standard == portable.

– Hans Passant
Mar 21 '17 at 22:41

4

4

There was one from Xamarin too, but these other ones don't add any value to the question :)

– Gigi
Mar 21 '17 at 22:42

There was one from Xamarin too, but these other ones don't add any value to the question :)

– Gigi
Mar 21 '17 at 22:42

7

7

Well, they do. The core idea is the they gave up on the portable approach, it suffered too heavily from the n! problem with way too many profiles. So now you've got 7 standards to choose from. Most are not actually portable right now :) .NETCore is not done by a long shot, probably takes another two years at the clip they are going.

– Hans Passant
Mar 21 '17 at 22:47

Well, they do. The core idea is the they gave up on the portable approach, it suffered too heavily from the n! problem with way too many profiles. So now you've got 7 standards to choose from. Most are not actually portable right now :) .NETCore is not done by a long shot, probably takes another two years at the clip they are going.

– Hans Passant
Mar 21 '17 at 22:47

5

5

OP said "at least 3 different types". The post was accurate.

– Dan Friedman
Sep 19 '17 at 20:49

OP said "at least 3 different types". The post was accurate.

– Dan Friedman
Sep 19 '17 at 20:49

and also there is Universal Windows

– doganak
Feb 20 '18 at 12:06

and also there is Universal Windows

– doganak
Feb 20 '18 at 12:06

 | 
show 3 more comments

9 Answers
9

active

oldest

votes

418

When should we use one over the other?

The decision is a trade-off between compatibility and API access.

Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.

For example, a library that targets .NET Standard 1.3 will be compatible with apps that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR package is compatible with .NET Core but not with .NET Standard.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

The Package-based frameworks section describes the difference.

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Why do both exist?

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

share|improve this answer

edited Feb 11 at 10:01

niico

3,836105197

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Very good answer. An additional question though (relates to this question: why is an application model necessary to run unit tests? This was never the case in the past, when we used non-runnable class libraries to hold collections of unit tests.
  
  – Gigi
  Mar 22 '17 at 8:22
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I've updated my answer to the linked question. TL;DR; In the past, class libraries targeted the full framework, which includes an application model.
  
  – Shaun Luttin
  Mar 22 '17 at 16:37
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  You forgot to cover Class Library (.NET Framework), is it compatible with .NET Standard and .NET Core?
  
  – Tomas
  Jul 11 '18 at 11:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Tomas, As .net standard can be understood as an interface rather than a library, then any library built against a specific version of .net standard can be referenced by either .net framework, or .net core, or other .net variant that implements that specific version of .net standard. So a .net framework or a .net core library is "compatible" with any .net standard library, provided that library is build against a version of .net standard that the .net framework or .net core libraries implement. .net framework and .net core are not compatible with each other. they target different runtimes.
  
  – Thanasis Ioannidis
  Sep 5 '18 at 13:55
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This diagram really helped me get it.
  
  – jpaugh
  Nov 13 '18 at 15:31
  

  
  
  
  

 | 
show 4 more comments

282

A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library

.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)

.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard

To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.

Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.

To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All. As pictures are worth a thousand words, the following will make things very clear:

1. Your current application scenario (fragmented)

Like most of us, you are probably in the situation below:
(.Net Framework, Xamarin and now .Net Core flavoured applications)

2. What the .Net Standard Library will enable for you (cross-framework compatibility)

Implementing a .Net Standard Library allows code sharing across all these different flavours:

For the impatient:

1. 
   .NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services:


2. 
   .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.


3. 
   .NET Standard 2.0 will be implemented by .NET Framework, .NET Core,
   and Xamarin. For .NET Core, this will add many of the existing APIs
   that have been requested.


4. 
   .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.


5. 
   .NET Standard will replace Portable Class Libraries (PCLs) as the
   tooling story for building multi-platform .NET libraries.

For a table to help understand what the highest version of .NET Standard that you can target, based on which .NET platforms you intend to run on, head over here.

Sources: MSDN: Introducing .Net Standard

share|improve this answer

edited Jul 25 '18 at 5:25

Moes

9,26644150

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  ASP.NET Core is a little misplaced in that graphic, as it can be used with the full .NET Framework, not only .NET Core, because it actually targets .NET Standard.
  
  – Neme
  Aug 20 '17 at 11:33
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  But you can create an ASP.NET Core app with the full .NET Framework - ASP.NET Core really belongs to the same layer as .NET Standard does. It's not constrained to just .NET Core.
  
  – Neme
  Aug 20 '17 at 18:29
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I'm not talking about combining .NET Core & .NET Framework. My point is that ASP.NET Core isn't dependent on .NET Core at all, despite the name. It is written as a library that targets .NET Standard, therefore you can use it everywhere you can use .NET Standard. Yes, they made a mistake in that image.
  
  – Neme
  Aug 20 '17 at 19:50
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  You can see it here: msdnshared.blob.core.windows.net/media/2017/03/new-project.png
  
  – Neme
  Aug 20 '17 at 19:52
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  github.com/aspnet/home/issues/2022#issuecomment-300786299
  
  – Neme
  Aug 20 '17 at 20:02
  

  
  
  
  

 | 
show 7 more comments

71

So the short answer would be:

IAnimal == .NetStandard (General)

ICat == .NetCore (Less General)

IDog == .NetFramework (Specific / oldest and has the most features)

share|improve this answer

edited Jun 18 '18 at 18:31

Cody

3,7941653113

answered Mar 27 '17 at 0:39

JoeJoe

97123

• 
  
  
  

  
  22
  

  
  
  
  
  
  

  
  
  @Joe.wang as I see it is bad that it messes the relationship between .NET Core and .NET Framework. If .NET Core is the bird, then .NET Framework cannot be the eagle (maybe cat is more suitable).
  
  – Lex Li
  Jun 27 '17 at 0:17
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  
  @LexLi is right, this muddies the waters. .NET Framework is not a subtype of .NET Core.
  
  – Eric Eskildsen
  Jul 19 '17 at 16:54
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  If we're using type implementation euphemisms, shouldn't IEagle be Eagle, i.e.; concrete?
  
  – die maus
  Aug 8 '17 at 13:31
  
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  this may look bit fancy but not acurate
  
  – afr0
  Sep 11 '17 at 6:28
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  The original comment by @Joe sounded more accurate. edited answer by Community made it confusing
  
  – Nandun
  Jan 11 '18 at 15:53
  

  
  
  
  

 | 
show 5 more comments

55

.Net Framework and .Net Core are two different implementations of the .Net runtime. Both Core and Framework (but especially Framework) have different profiles that include larger or smaller (or just plain different) selections of the many APIs and assemblies Microsoft has created for .Net, depending on where they are installed and in what profile. For example, there are some different APIs available in Universal Windows apps than in the "normal" Windows profile. Even on Windows, you might have the "Client" profile vs the "Full" profile. Additionally, there are other implementations (like Mono) that have their own sets of libraries.

.Net Standard is a specification for which sets of API libraries and assemblies must be available. An app written for .Net Standard 1.0 should be able to compile and run with any version of Framework, Core, Mono, etc, that advertises support for the .Net Standard 1.0 collection of libraries. Similar is true for .Net Standard 1.1, 1.5, 1.6, 2.0, etc. As long as the runtime provides support for the version of Standard targeted by your program, your program should run there.

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn't mean you can't take dependencies on other assemblies, or APIs published by other vendors (ie: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .Net Standard. .Net Standard is evolving quickly, but it's still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .Net Standard versions are much nicer and more full-featured).

On the other hand, an app targeted at Standard should be able to be used in more deployment situations, since in theory it can run with Core, Framework, Mono, etc. For a class library project looking for wide distribution, that's an attractive promise. For a class library project used mainly for internal purposes, it may not be as much of a concern.

.Net Standard can also be useful in situations where the SysAdmin team is wanting to move from ASP.Net on Windows to ASP.Net for .Net Core on Linux for philosophical or cost reasons, but the Development team wants to continue working against .Net Framework in Visual Studio on Windows.

share|improve this answer

edited Nov 3 '18 at 16:17

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  While a good overview of what .NET Core and .NET Standard are, this answer fails to answer the question about class libraries targeting each of these.
  
  – Gigi
  Mar 22 '17 at 8:17
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  If that's your goal, the question needs to be closed as either "unclear what you're asking", since there are always going to be too many situational specifics that play into a given person's environment for us to ever just tell you what to do, or as "Too Broad" if you're asking about the general case. All we can do here is give you info about the products, so you can be informed for making your own decision.
  
  – Joel Coehoorn
  May 1 '17 at 16:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is clearly not the case, as another has accurately answered the question. My question was about the class libraries. Your answer was about the frameworks.
  
  – Gigi
  May 2 '17 at 18:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JoelCoehoorn very technically explained.
  
  – BerBar
  Jan 2 at 3:18
  

  
  
  
  

add a comment | 

12

.NET Framework and .NET Core are both frameworks.

.NET Standard is standard (in other words, specification).

You can make executable project (like Console application, or ASP.NET application) with .NET Framework and .NET Core, but not with .NET Standard.

With .NET Standard you can make only class-library project that cannot be executed standalone and should be referenced by another .NET Core or .NET Framework executable project.

share|improve this answer

answered Aug 8 '18 at 12:58

bsidebside

167210

add a comment | 

7

.NET Standard: Think of it as a big standard library. When using this as a dependency you can only make libraries (.DLLs), not executables. A library made with .NET standard as a dependency can be added to a Xamarin.Android, a Xamarin.iOS, a .NET Core Windows/OSX/Linux project.

.NET Core: Think of it as the continuation of the old .NET framework, just it's opensource and some stuff is not yet implemented and others got deprecated. It extends the .NET standard with extra functions, but only runs on Desktops. When adding this as a dependency you can make runnable apps on Windows, Linux and OSX. (Although console only for now, no GUIs). So .NET Core = .NET Standard + Desktop specific stuff.

Also UWP uses it and the new ASP.NET core uses it as a dependency too.

share|improve this answer

answered Dec 26 '17 at 3:45

community wiki

sydd

add a comment | 

7

Hope this will help to understand the relationship between .NET Standard API surface and other .NET platforms. Each interface represents a target framework and methods represents groups of APIs available on that target framework.

namespace Analogy

{

  // .NET Standard



interface INetStandard10

{

    void Primitives();

    void Reflection();

    void Tasks();

    void Xml();

    void Collections();

    void Linq();

}



interface INetStandard11 : INetStandard10

{

    void ConcurrentCollections();

    void LinqParallel();

    void Compression();

    void HttpClient();

}



interface INetStandard12 : INetStandard11

{

    void ThreadingTimer();

}



interface INetStandard13 : INetStandard12

{

    //.NET Standard 1.3 specific APIs

}



// And so on ...





// .NET Framework 



interface INetFramework45 : INetStandard11

{

    void FileSystem();

    void Console();

    void ThreadPool();

    void Crypto();

    void WebSockets();

    void Process();

    void Drawing();

    void SystemWeb();

    void WPF();

    void WindowsForms();

    void WCF();

}



interface INetFramework451 : INetFramework45, INetStandard12

{

    // .NET Framework 4.5.1 specific APIs

}



interface INetFramework452 : INetFramework451, INetStandard12

{

    // .NET Framework 4.5.2 specific APIs

}



interface INetFramework46 : INetFramework452, INetStandard13

{

    // .NET Framework 4.6 specific APIs

}



interface INetFramework461 : INetFramework46, INetStandard14

{

    // .NET Framework 4.6.1 specific APIs

}



interface INetFramework462 : INetFramework461, INetStandard15

{

    // .NET Framework 4.6.2 specific APIs

}



// .NET Core

interface INetCoreApp10 : INetStandard15

{

    // TODO: .NET Core 1.0 specific APIs

}

// Windows Universal Platform

interface IWindowsUniversalPlatform : INetStandard13

{

    void GPS();

    void Xaml();

}



// Xamarin 

interface IXamarinIOS : INetStandard15

{

    void AppleAPIs();

}



interface IXamarinAndroid : INetStandard15

{

    void GoogleAPIs();

}    

// Future platform



interface ISomeFuturePlatform : INetStandard13

{

    // A future platform chooses to implement a specific .NET Standard version.

    // All libraries that target that version are instantly compatible with this new

    // platform

}

}

Source

share|improve this answer

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

add a comment | 

5

.Net Standard exists mainly to improve code sharing and make the APIs available in each .Net implementation more consistent.

While creating Libraries we can have target as.Net Standard 2.0 so that the library created would be compaitible with different versions of .Net Framework including .Net Core,Mono..

share|improve this answer

answered Aug 15 '17 at 15:50

ARPARP

5111

add a comment | 

2

Another way of explaining the difference could be with real world examples, as most of us mortals will use existing tools and frameworks (Xamarin, Unity, etc) to do the job.

So, with .NET Framework you have all the .NET tools to work with but you can only target Windows applications (UWP, Winforms, ASP.NET, etc). Since .NET Framework is closed source there isn't much to do about it.

With .NET Core you have less tools but you can target the main Desktop Platforms (Windows, Linux, Mac). This is specially useful in ASP.NET Core applications, since you can now host Asp.net in Linux (cheaper hosting prices). Now, since .NET Core was open sourced, it's technically possible to develop libraries for other platforms. But since there aren't frameworks that support it, i don't think that's a good idea.

With .NET Standard you have even less tools but you can target all/most platforms. You can target Mobile thanks to Xamarin, and you can even target Game Consoles thanks to Mono/Unity.

In a real world application you may need to use all of them. For example, i developed a point of sale application that had the following architecture:

Shared both Server and Client:

• A .NET Standard library that handles the Models of my application.

Since it's a .NET Standard library, it can be used in any other library.

Server Side (Web API):

• A .NET Standard (could be Core as well) library that handles all the
  database connections.




• A .NET Core project that handles the Rest API and makes use of the
  database library.

As this is developed in .NET Core, i can host the application on a Linux server.

Client Side (MVVM with WPF + Xamarin.Forms Android/IOS):

• A .NET Standard library that handles the client API connection.




• A .NET Standard library that handles the ViewModels Logic. Used in
  all the views.




• A .NET Framework WPF application that handles the WPF views for a
  windows application.




• A .NET Standard library that handles Xamarin Forms views.




• A Xamarin Android and Xamarin IOS project.

So you can see that there's a big advantage here in the client side of the application since i can reuse both .NET Standard libraries (Client API and ViewModels) and just make views with no logic for the WPF, Xamarin and IOS applications.

share|improve this answer

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

add a comment | 

Your Answer

StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question. Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.


• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f42939454%2fwhat-is-the-difference-between-net-core-and-net-standard-class-library-project%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

9 Answers
9

active

oldest

votes

9 Answers
9

active

oldest

votes

active

oldest

votes

active

oldest

votes

418

When should we use one over the other?

The decision is a trade-off between compatibility and API access.

Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.

For example, a library that targets .NET Standard 1.3 will be compatible with apps that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR package is compatible with .NET Core but not with .NET Standard.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

The Package-based frameworks section describes the difference.

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Why do both exist?

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

share|improve this answer

edited Feb 11 at 10:01

niico

3,836105197

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Very good answer. An additional question though (relates to this question: why is an application model necessary to run unit tests? This was never the case in the past, when we used non-runnable class libraries to hold collections of unit tests.
  
  – Gigi
  Mar 22 '17 at 8:22
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I've updated my answer to the linked question. TL;DR; In the past, class libraries targeted the full framework, which includes an application model.
  
  – Shaun Luttin
  Mar 22 '17 at 16:37
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  You forgot to cover Class Library (.NET Framework), is it compatible with .NET Standard and .NET Core?
  
  – Tomas
  Jul 11 '18 at 11:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Tomas, As .net standard can be understood as an interface rather than a library, then any library built against a specific version of .net standard can be referenced by either .net framework, or .net core, or other .net variant that implements that specific version of .net standard. So a .net framework or a .net core library is "compatible" with any .net standard library, provided that library is build against a version of .net standard that the .net framework or .net core libraries implement. .net framework and .net core are not compatible with each other. they target different runtimes.
  
  – Thanasis Ioannidis
  Sep 5 '18 at 13:55
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This diagram really helped me get it.
  
  – jpaugh
  Nov 13 '18 at 15:31
  

  
  
  
  

 | 
show 4 more comments

418

When should we use one over the other?

The decision is a trade-off between compatibility and API access.

Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.

For example, a library that targets .NET Standard 1.3 will be compatible with apps that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR package is compatible with .NET Core but not with .NET Standard.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

The Package-based frameworks section describes the difference.

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Why do both exist?

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

share|improve this answer

edited Feb 11 at 10:01

niico

3,836105197

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Very good answer. An additional question though (relates to this question: why is an application model necessary to run unit tests? This was never the case in the past, when we used non-runnable class libraries to hold collections of unit tests.
  
  – Gigi
  Mar 22 '17 at 8:22
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I've updated my answer to the linked question. TL;DR; In the past, class libraries targeted the full framework, which includes an application model.
  
  – Shaun Luttin
  Mar 22 '17 at 16:37
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  You forgot to cover Class Library (.NET Framework), is it compatible with .NET Standard and .NET Core?
  
  – Tomas
  Jul 11 '18 at 11:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Tomas, As .net standard can be understood as an interface rather than a library, then any library built against a specific version of .net standard can be referenced by either .net framework, or .net core, or other .net variant that implements that specific version of .net standard. So a .net framework or a .net core library is "compatible" with any .net standard library, provided that library is build against a version of .net standard that the .net framework or .net core libraries implement. .net framework and .net core are not compatible with each other. they target different runtimes.
  
  – Thanasis Ioannidis
  Sep 5 '18 at 13:55
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This diagram really helped me get it.
  
  – jpaugh
  Nov 13 '18 at 15:31
  

  
  
  
  

 | 
show 4 more comments

418

418

418

When should we use one over the other?

The decision is a trade-off between compatibility and API access.

Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.

For example, a library that targets .NET Standard 1.3 will be compatible with apps that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR package is compatible with .NET Core but not with .NET Standard.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

The Package-based frameworks section describes the difference.

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Why do both exist?

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

share|improve this answer

edited Feb 11 at 10:01

niico

3,836105197

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

When should we use one over the other?

The decision is a trade-off between compatibility and API access.

Use a .NET Standard library when you want to increase the number of apps that will be compatible with your library, and you are okay with a decrease in the .NET API surface area your library can access.

Use a .NET Core library when you want to increase the .NET API surface area your library can access, and you are okay with allowing only .NET Core apps to be compatible with your library.

For example, a library that targets .NET Standard 1.3 will be compatible with apps that target .NET Framework 4.6, .NET Core 1.0, Universal Windows Platform 10.0, and any other platform that supports .NET Standard 1.3. The library will not have access to some parts of the .NET API, though. For instance, the Microsoft.NETCore.CoreCLR package is compatible with .NET Core but not with .NET Standard.

What is the difference between Class Library (.NET Standard) and Class Library (.NET Core)?

The Package-based frameworks section describes the difference.

Compatibility: Libraries that target .NET Standard will run on any .NET Standard compliant runtime, such as .NET Core, .NET Framework, Mono/Xamarin. On the other hand, libraries that target .NET Core can only run on the .NET Core runtime.

API Surface Area: .NET Standard libraries come with everything in NETStandard.Library whereas .NET Core libraries come with everything in Microsoft.NETCore.App. The latter includes approximately 20 additional libraries, some of which we can add manually to our .NET Standard library (such as System.Threading.Thread) and some of which are not compatible with the .NET Standard (such as Microsoft.NETCore.CoreCLR).

Also, .NET Core libraries specify a runtime and come with an application model. That's important, for instance, to make unit test class libraries runnable.

Why do both exist?

Ignoring libraries for a moment, the reason that .NET Standard exists is for portability; it defines a set of APIs that .NET platforms agree to implement. Any platform that implements a .NET Standard is compatible with libraries that target that .NET Standard. One of those compatible platforms is .NET Core.

Coming back to libraries, the .NET Standard library templates exist to run on multiple runtimes (at the expense of API surface area). Obversely, the .NET Core library templates exist to access more API surface area (at the expense of compatibility) and to specify a platform against which to build an executable.

share|improve this answer

edited Feb 11 at 10:01

niico

3,836105197

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

share|improve this answer

share|improve this answer

edited Feb 11 at 10:01

niico

3,836105197

edited Feb 11 at 10:01

niico

3,836105197

edited Feb 11 at 10:01

niico

3,836105197

3,836105197

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

answered Mar 21 '17 at 23:33

Shaun LuttinShaun Luttin

61.3k34233292

61.3k34233292

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Very good answer. An additional question though (relates to this question: why is an application model necessary to run unit tests? This was never the case in the past, when we used non-runnable class libraries to hold collections of unit tests.
  
  – Gigi
  Mar 22 '17 at 8:22
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I've updated my answer to the linked question. TL;DR; In the past, class libraries targeted the full framework, which includes an application model.
  
  – Shaun Luttin
  Mar 22 '17 at 16:37
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  You forgot to cover Class Library (.NET Framework), is it compatible with .NET Standard and .NET Core?
  
  – Tomas
  Jul 11 '18 at 11:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Tomas, As .net standard can be understood as an interface rather than a library, then any library built against a specific version of .net standard can be referenced by either .net framework, or .net core, or other .net variant that implements that specific version of .net standard. So a .net framework or a .net core library is "compatible" with any .net standard library, provided that library is build against a version of .net standard that the .net framework or .net core libraries implement. .net framework and .net core are not compatible with each other. they target different runtimes.
  
  – Thanasis Ioannidis
  Sep 5 '18 at 13:55
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This diagram really helped me get it.
  
  – jpaugh
  Nov 13 '18 at 15:31
  

  
  
  
  

 | 
show 4 more comments

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  Very good answer. An additional question though (relates to this question: why is an application model necessary to run unit tests? This was never the case in the past, when we used non-runnable class libraries to hold collections of unit tests.
  
  – Gigi
  Mar 22 '17 at 8:22
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I've updated my answer to the linked question. TL;DR; In the past, class libraries targeted the full framework, which includes an application model.
  
  – Shaun Luttin
  Mar 22 '17 at 16:37
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  You forgot to cover Class Library (.NET Framework), is it compatible with .NET Standard and .NET Core?
  
  – Tomas
  Jul 11 '18 at 11:35
  
  
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @Tomas, As .net standard can be understood as an interface rather than a library, then any library built against a specific version of .net standard can be referenced by either .net framework, or .net core, or other .net variant that implements that specific version of .net standard. So a .net framework or a .net core library is "compatible" with any .net standard library, provided that library is build against a version of .net standard that the .net framework or .net core libraries implement. .net framework and .net core are not compatible with each other. they target different runtimes.
  
  – Thanasis Ioannidis
  Sep 5 '18 at 13:55
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  This diagram really helped me get it.
  
  – jpaugh
  Nov 13 '18 at 15:31
  

  
  
  
  

1

1

Very good answer. An additional question though (relates to this question: why is an application model necessary to run unit tests? This was never the case in the past, when we used non-runnable class libraries to hold collections of unit tests.

– Gigi
Mar 22 '17 at 8:22

Very good answer. An additional question though (relates to this question: why is an application model necessary to run unit tests? This was never the case in the past, when we used non-runnable class libraries to hold collections of unit tests.

– Gigi
Mar 22 '17 at 8:22

3

3

I've updated my answer to the linked question. TL;DR; In the past, class libraries targeted the full framework, which includes an application model.

– Shaun Luttin
Mar 22 '17 at 16:37

I've updated my answer to the linked question. TL;DR; In the past, class libraries targeted the full framework, which includes an application model.

– Shaun Luttin
Mar 22 '17 at 16:37

You forgot to cover Class Library (.NET Framework), is it compatible with .NET Standard and .NET Core?

– Tomas
Jul 11 '18 at 11:35

You forgot to cover Class Library (.NET Framework), is it compatible with .NET Standard and .NET Core?

– Tomas
Jul 11 '18 at 11:35

@Tomas, As .net standard can be understood as an interface rather than a library, then any library built against a specific version of .net standard can be referenced by either .net framework, or .net core, or other .net variant that implements that specific version of .net standard. So a .net framework or a .net core library is "compatible" with any .net standard library, provided that library is build against a version of .net standard that the .net framework or .net core libraries implement. .net framework and .net core are not compatible with each other. they target different runtimes.

– Thanasis Ioannidis
Sep 5 '18 at 13:55

@Tomas, As .net standard can be understood as an interface rather than a library, then any library built against a specific version of .net standard can be referenced by either .net framework, or .net core, or other .net variant that implements that specific version of .net standard. So a .net framework or a .net core library is "compatible" with any .net standard library, provided that library is build against a version of .net standard that the .net framework or .net core libraries implement. .net framework and .net core are not compatible with each other. they target different runtimes.

– Thanasis Ioannidis
Sep 5 '18 at 13:55

This diagram really helped me get it.

– jpaugh
Nov 13 '18 at 15:31

This diagram really helped me get it.

– jpaugh
Nov 13 '18 at 15:31

 | 
show 4 more comments

282

A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library

.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)

.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard

To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.

Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.

To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All. As pictures are worth a thousand words, the following will make things very clear:

1. Your current application scenario (fragmented)

Like most of us, you are probably in the situation below:
(.Net Framework, Xamarin and now .Net Core flavoured applications)

2. What the .Net Standard Library will enable for you (cross-framework compatibility)

Implementing a .Net Standard Library allows code sharing across all these different flavours:

For the impatient:

1. 
   .NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services:


2. 
   .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.


3. 
   .NET Standard 2.0 will be implemented by .NET Framework, .NET Core,
   and Xamarin. For .NET Core, this will add many of the existing APIs
   that have been requested.


4. 
   .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.


5. 
   .NET Standard will replace Portable Class Libraries (PCLs) as the
   tooling story for building multi-platform .NET libraries.

For a table to help understand what the highest version of .NET Standard that you can target, based on which .NET platforms you intend to run on, head over here.

Sources: MSDN: Introducing .Net Standard

share|improve this answer

edited Jul 25 '18 at 5:25

Moes

9,26644150

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  ASP.NET Core is a little misplaced in that graphic, as it can be used with the full .NET Framework, not only .NET Core, because it actually targets .NET Standard.
  
  – Neme
  Aug 20 '17 at 11:33
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  But you can create an ASP.NET Core app with the full .NET Framework - ASP.NET Core really belongs to the same layer as .NET Standard does. It's not constrained to just .NET Core.
  
  – Neme
  Aug 20 '17 at 18:29
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I'm not talking about combining .NET Core & .NET Framework. My point is that ASP.NET Core isn't dependent on .NET Core at all, despite the name. It is written as a library that targets .NET Standard, therefore you can use it everywhere you can use .NET Standard. Yes, they made a mistake in that image.
  
  – Neme
  Aug 20 '17 at 19:50
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  You can see it here: msdnshared.blob.core.windows.net/media/2017/03/new-project.png
  
  – Neme
  Aug 20 '17 at 19:52
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  github.com/aspnet/home/issues/2022#issuecomment-300786299
  
  – Neme
  Aug 20 '17 at 20:02
  

  
  
  
  

 | 
show 7 more comments

282

A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library

.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)

.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard

To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.

Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.

To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All. As pictures are worth a thousand words, the following will make things very clear:

1. Your current application scenario (fragmented)

Like most of us, you are probably in the situation below:
(.Net Framework, Xamarin and now .Net Core flavoured applications)

2. What the .Net Standard Library will enable for you (cross-framework compatibility)

Implementing a .Net Standard Library allows code sharing across all these different flavours:

For the impatient:

1. 
   .NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services:


2. 
   .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.


3. 
   .NET Standard 2.0 will be implemented by .NET Framework, .NET Core,
   and Xamarin. For .NET Core, this will add many of the existing APIs
   that have been requested.


4. 
   .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.


5. 
   .NET Standard will replace Portable Class Libraries (PCLs) as the
   tooling story for building multi-platform .NET libraries.

For a table to help understand what the highest version of .NET Standard that you can target, based on which .NET platforms you intend to run on, head over here.

Sources: MSDN: Introducing .Net Standard

share|improve this answer

edited Jul 25 '18 at 5:25

Moes

9,26644150

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  ASP.NET Core is a little misplaced in that graphic, as it can be used with the full .NET Framework, not only .NET Core, because it actually targets .NET Standard.
  
  – Neme
  Aug 20 '17 at 11:33
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  But you can create an ASP.NET Core app with the full .NET Framework - ASP.NET Core really belongs to the same layer as .NET Standard does. It's not constrained to just .NET Core.
  
  – Neme
  Aug 20 '17 at 18:29
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I'm not talking about combining .NET Core & .NET Framework. My point is that ASP.NET Core isn't dependent on .NET Core at all, despite the name. It is written as a library that targets .NET Standard, therefore you can use it everywhere you can use .NET Standard. Yes, they made a mistake in that image.
  
  – Neme
  Aug 20 '17 at 19:50
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  You can see it here: msdnshared.blob.core.windows.net/media/2017/03/new-project.png
  
  – Neme
  Aug 20 '17 at 19:52
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  github.com/aspnet/home/issues/2022#issuecomment-300786299
  
  – Neme
  Aug 20 '17 at 20:02
  

  
  
  
  

 | 
show 7 more comments

282

282

282

A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library

.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)

.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard

To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.

Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.

To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All. As pictures are worth a thousand words, the following will make things very clear:

1. Your current application scenario (fragmented)

Like most of us, you are probably in the situation below:
(.Net Framework, Xamarin and now .Net Core flavoured applications)

2. What the .Net Standard Library will enable for you (cross-framework compatibility)

Implementing a .Net Standard Library allows code sharing across all these different flavours:

For the impatient:

1. 
   .NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services:


2. 
   .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.


3. 
   .NET Standard 2.0 will be implemented by .NET Framework, .NET Core,
   and Xamarin. For .NET Core, this will add many of the existing APIs
   that have been requested.


4. 
   .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.


5. 
   .NET Standard will replace Portable Class Libraries (PCLs) as the
   tooling story for building multi-platform .NET libraries.

For a table to help understand what the highest version of .NET Standard that you can target, based on which .NET platforms you intend to run on, head over here.

Sources: MSDN: Introducing .Net Standard

share|improve this answer

edited Jul 25 '18 at 5:25

Moes

9,26644150

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

A .Net Core Class Library is built upon the .Net Standard. If you want to implement a library that is portable to the .Net Framework, .Net Core and Xamarin, choose a .Net Standard Library

.Net Core will ultimately implement .Net Standard 2 (as will Xamarin and .Net Framework)

.Net Core, Xamarin and .Net Framework can, therefore, be identified as flavours of .Net Standard

To future-proof your applications for code sharing and reuse , you would rather implement .Net Standard libraries.

Microsoft also recommends that you use .NET Standard instead of Portable Class Libraries.

To quote MSDN as an authoritative source, .Net Standard is intended to be One Library to Rule Them All. As pictures are worth a thousand words, the following will make things very clear:

1. Your current application scenario (fragmented)

Like most of us, you are probably in the situation below:
(.Net Framework, Xamarin and now .Net Core flavoured applications)

2. What the .Net Standard Library will enable for you (cross-framework compatibility)

Implementing a .Net Standard Library allows code sharing across all these different flavours:

For the impatient:

1. 
   .NET Standard solves the code sharing problem for .NET developers across all platforms by bringing all the APIs that you expect and love across the environments that you need: desktop applications, mobile apps & games, and cloud services:


2. 
   .NET Standard is a set of APIs that all .NET platforms have to implement. This unifies the .NET platforms and prevents future fragmentation.


3. 
   .NET Standard 2.0 will be implemented by .NET Framework, .NET Core,
   and Xamarin. For .NET Core, this will add many of the existing APIs
   that have been requested.


4. 
   .NET Standard 2.0 includes a compatibility shim for .NET Framework binaries, significantly increasing the set of libraries that you can reference from your .NET Standard libraries.


5. 
   .NET Standard will replace Portable Class Libraries (PCLs) as the
   tooling story for building multi-platform .NET libraries.

For a table to help understand what the highest version of .NET Standard that you can target, based on which .NET platforms you intend to run on, head over here.

Sources: MSDN: Introducing .Net Standard

share|improve this answer

edited Jul 25 '18 at 5:25

Moes

9,26644150

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

share|improve this answer

share|improve this answer

edited Jul 25 '18 at 5:25

Moes

9,26644150

edited Jul 25 '18 at 5:25

Moes

9,26644150

edited Jul 25 '18 at 5:25

Moes

9,26644150

9,26644150

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

answered Jul 1 '17 at 13:44

user919426user919426

4,34673255

4,34673255

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  ASP.NET Core is a little misplaced in that graphic, as it can be used with the full .NET Framework, not only .NET Core, because it actually targets .NET Standard.
  
  – Neme
  Aug 20 '17 at 11:33
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  But you can create an ASP.NET Core app with the full .NET Framework - ASP.NET Core really belongs to the same layer as .NET Standard does. It's not constrained to just .NET Core.
  
  – Neme
  Aug 20 '17 at 18:29
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I'm not talking about combining .NET Core & .NET Framework. My point is that ASP.NET Core isn't dependent on .NET Core at all, despite the name. It is written as a library that targets .NET Standard, therefore you can use it everywhere you can use .NET Standard. Yes, they made a mistake in that image.
  
  – Neme
  Aug 20 '17 at 19:50
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  You can see it here: msdnshared.blob.core.windows.net/media/2017/03/new-project.png
  
  – Neme
  Aug 20 '17 at 19:52
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  github.com/aspnet/home/issues/2022#issuecomment-300786299
  
  – Neme
  Aug 20 '17 at 20:02
  

  
  
  
  

 | 
show 7 more comments

• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  ASP.NET Core is a little misplaced in that graphic, as it can be used with the full .NET Framework, not only .NET Core, because it actually targets .NET Standard.
  
  – Neme
  Aug 20 '17 at 11:33
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  But you can create an ASP.NET Core app with the full .NET Framework - ASP.NET Core really belongs to the same layer as .NET Standard does. It's not constrained to just .NET Core.
  
  – Neme
  Aug 20 '17 at 18:29
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  I'm not talking about combining .NET Core & .NET Framework. My point is that ASP.NET Core isn't dependent on .NET Core at all, despite the name. It is written as a library that targets .NET Standard, therefore you can use it everywhere you can use .NET Standard. Yes, they made a mistake in that image.
  
  – Neme
  Aug 20 '17 at 19:50
  
  
  

  
  
  
  


• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  You can see it here: msdnshared.blob.core.windows.net/media/2017/03/new-project.png
  
  – Neme
  Aug 20 '17 at 19:52
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  github.com/aspnet/home/issues/2022#issuecomment-300786299
  
  – Neme
  Aug 20 '17 at 20:02
  

  
  
  
  

2

2

ASP.NET Core is a little misplaced in that graphic, as it can be used with the full .NET Framework, not only .NET Core, because it actually targets .NET Standard.

– Neme
Aug 20 '17 at 11:33

ASP.NET Core is a little misplaced in that graphic, as it can be used with the full .NET Framework, not only .NET Core, because it actually targets .NET Standard.

– Neme
Aug 20 '17 at 11:33

2

2

But you can create an ASP.NET Core app with the full .NET Framework - ASP.NET Core really belongs to the same layer as .NET Standard does. It's not constrained to just .NET Core.

– Neme
Aug 20 '17 at 18:29

But you can create an ASP.NET Core app with the full .NET Framework - ASP.NET Core really belongs to the same layer as .NET Standard does. It's not constrained to just .NET Core.

– Neme
Aug 20 '17 at 18:29

3

3

I'm not talking about combining .NET Core & .NET Framework. My point is that ASP.NET Core isn't dependent on .NET Core at all, despite the name. It is written as a library that targets .NET Standard, therefore you can use it everywhere you can use .NET Standard. Yes, they made a mistake in that image.

– Neme
Aug 20 '17 at 19:50

I'm not talking about combining .NET Core & .NET Framework. My point is that ASP.NET Core isn't dependent on .NET Core at all, despite the name. It is written as a library that targets .NET Standard, therefore you can use it everywhere you can use .NET Standard. Yes, they made a mistake in that image.

– Neme
Aug 20 '17 at 19:50

1

1

You can see it here: msdnshared.blob.core.windows.net/media/2017/03/new-project.png

– Neme
Aug 20 '17 at 19:52

You can see it here: msdnshared.blob.core.windows.net/media/2017/03/new-project.png

– Neme
Aug 20 '17 at 19:52

2

2

github.com/aspnet/home/issues/2022#issuecomment-300786299

– Neme
Aug 20 '17 at 20:02

github.com/aspnet/home/issues/2022#issuecomment-300786299

– Neme
Aug 20 '17 at 20:02

 | 
show 7 more comments

71

So the short answer would be:

IAnimal == .NetStandard (General)

ICat == .NetCore (Less General)

IDog == .NetFramework (Specific / oldest and has the most features)

share|improve this answer

edited Jun 18 '18 at 18:31

Cody

3,7941653113

answered Mar 27 '17 at 0:39

JoeJoe

97123

• 
  
  
  

  
  22
  

  
  
  
  
  
  

  
  
  @Joe.wang as I see it is bad that it messes the relationship between .NET Core and .NET Framework. If .NET Core is the bird, then .NET Framework cannot be the eagle (maybe cat is more suitable).
  
  – Lex Li
  Jun 27 '17 at 0:17
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  
  @LexLi is right, this muddies the waters. .NET Framework is not a subtype of .NET Core.
  
  – Eric Eskildsen
  Jul 19 '17 at 16:54
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  If we're using type implementation euphemisms, shouldn't IEagle be Eagle, i.e.; concrete?
  
  – die maus
  Aug 8 '17 at 13:31
  
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  this may look bit fancy but not acurate
  
  – afr0
  Sep 11 '17 at 6:28
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  The original comment by @Joe sounded more accurate. edited answer by Community made it confusing
  
  – Nandun
  Jan 11 '18 at 15:53
  

  
  
  
  

 | 
show 5 more comments

71

So the short answer would be:

IAnimal == .NetStandard (General)

ICat == .NetCore (Less General)

IDog == .NetFramework (Specific / oldest and has the most features)

share|improve this answer

edited Jun 18 '18 at 18:31

Cody

3,7941653113

answered Mar 27 '17 at 0:39

JoeJoe

97123

• 
  
  
  

  
  22
  

  
  
  
  
  
  

  
  
  @Joe.wang as I see it is bad that it messes the relationship between .NET Core and .NET Framework. If .NET Core is the bird, then .NET Framework cannot be the eagle (maybe cat is more suitable).
  
  – Lex Li
  Jun 27 '17 at 0:17
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  
  @LexLi is right, this muddies the waters. .NET Framework is not a subtype of .NET Core.
  
  – Eric Eskildsen
  Jul 19 '17 at 16:54
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  If we're using type implementation euphemisms, shouldn't IEagle be Eagle, i.e.; concrete?
  
  – die maus
  Aug 8 '17 at 13:31
  
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  this may look bit fancy but not acurate
  
  – afr0
  Sep 11 '17 at 6:28
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  The original comment by @Joe sounded more accurate. edited answer by Community made it confusing
  
  – Nandun
  Jan 11 '18 at 15:53
  

  
  
  
  

 | 
show 5 more comments

71

71

71

So the short answer would be:

IAnimal == .NetStandard (General)

ICat == .NetCore (Less General)

IDog == .NetFramework (Specific / oldest and has the most features)

share|improve this answer

edited Jun 18 '18 at 18:31

Cody

3,7941653113

answered Mar 27 '17 at 0:39

JoeJoe

97123

So the short answer would be:

IAnimal == .NetStandard (General)

ICat == .NetCore (Less General)

IDog == .NetFramework (Specific / oldest and has the most features)

share|improve this answer

edited Jun 18 '18 at 18:31

Cody

3,7941653113

answered Mar 27 '17 at 0:39

JoeJoe

97123

share|improve this answer

share|improve this answer

edited Jun 18 '18 at 18:31

Cody

3,7941653113

edited Jun 18 '18 at 18:31

Cody

3,7941653113

edited Jun 18 '18 at 18:31

Cody

3,7941653113

3,7941653113

answered Mar 27 '17 at 0:39

JoeJoe

97123

answered Mar 27 '17 at 0:39

JoeJoe

97123

answered Mar 27 '17 at 0:39

JoeJoe

97123

97123

• 
  
  
  

  
  22
  

  
  
  
  
  
  

  
  
  @Joe.wang as I see it is bad that it messes the relationship between .NET Core and .NET Framework. If .NET Core is the bird, then .NET Framework cannot be the eagle (maybe cat is more suitable).
  
  – Lex Li
  Jun 27 '17 at 0:17
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  
  @LexLi is right, this muddies the waters. .NET Framework is not a subtype of .NET Core.
  
  – Eric Eskildsen
  Jul 19 '17 at 16:54
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  If we're using type implementation euphemisms, shouldn't IEagle be Eagle, i.e.; concrete?
  
  – die maus
  Aug 8 '17 at 13:31
  
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  this may look bit fancy but not acurate
  
  – afr0
  Sep 11 '17 at 6:28
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  The original comment by @Joe sounded more accurate. edited answer by Community made it confusing
  
  – Nandun
  Jan 11 '18 at 15:53
  

  
  
  
  

 | 
show 5 more comments

• 
  
  
  

  
  22
  

  
  
  
  
  
  

  
  
  @Joe.wang as I see it is bad that it messes the relationship between .NET Core and .NET Framework. If .NET Core is the bird, then .NET Framework cannot be the eagle (maybe cat is more suitable).
  
  – Lex Li
  Jun 27 '17 at 0:17
  

  
  
  
  


• 
  
  
  

  
  6
  

  
  
  
  
  
  

  
  
  @LexLi is right, this muddies the waters. .NET Framework is not a subtype of .NET Core.
  
  – Eric Eskildsen
  Jul 19 '17 at 16:54
  

  
  
  
  


• 
  
  
  

  
  2
  

  
  
  
  
  
  

  
  
  If we're using type implementation euphemisms, shouldn't IEagle be Eagle, i.e.; concrete?
  
  – die maus
  Aug 8 '17 at 13:31
  
  
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  this may look bit fancy but not acurate
  
  – afr0
  Sep 11 '17 at 6:28
  

  
  
  
  


• 
  
  
  

  
  3
  

  
  
  
  
  
  

  
  
  The original comment by @Joe sounded more accurate. edited answer by Community made it confusing
  
  – Nandun
  Jan 11 '18 at 15:53
  

  
  
  
  

22

22

@Joe.wang as I see it is bad that it messes the relationship between .NET Core and .NET Framework. If .NET Core is the bird, then .NET Framework cannot be the eagle (maybe cat is more suitable).

– Lex Li
Jun 27 '17 at 0:17

@Joe.wang as I see it is bad that it messes the relationship between .NET Core and .NET Framework. If .NET Core is the bird, then .NET Framework cannot be the eagle (maybe cat is more suitable).

– Lex Li
Jun 27 '17 at 0:17

6

6

@LexLi is right, this muddies the waters. .NET Framework is not a subtype of .NET Core.

– Eric Eskildsen
Jul 19 '17 at 16:54

@LexLi is right, this muddies the waters. .NET Framework is not a subtype of .NET Core.

– Eric Eskildsen
Jul 19 '17 at 16:54

2

2

If we're using type implementation euphemisms, shouldn't IEagle be Eagle, i.e.; concrete?

– die maus
Aug 8 '17 at 13:31

If we're using type implementation euphemisms, shouldn't IEagle be Eagle, i.e.; concrete?

– die maus
Aug 8 '17 at 13:31

3

3

this may look bit fancy but not acurate

– afr0
Sep 11 '17 at 6:28

this may look bit fancy but not acurate

– afr0
Sep 11 '17 at 6:28

3

3

The original comment by @Joe sounded more accurate. edited answer by Community made it confusing

– Nandun
Jan 11 '18 at 15:53

The original comment by @Joe sounded more accurate. edited answer by Community made it confusing

– Nandun
Jan 11 '18 at 15:53

 | 
show 5 more comments

55

.Net Framework and .Net Core are two different implementations of the .Net runtime. Both Core and Framework (but especially Framework) have different profiles that include larger or smaller (or just plain different) selections of the many APIs and assemblies Microsoft has created for .Net, depending on where they are installed and in what profile. For example, there are some different APIs available in Universal Windows apps than in the "normal" Windows profile. Even on Windows, you might have the "Client" profile vs the "Full" profile. Additionally, there are other implementations (like Mono) that have their own sets of libraries.

.Net Standard is a specification for which sets of API libraries and assemblies must be available. An app written for .Net Standard 1.0 should be able to compile and run with any version of Framework, Core, Mono, etc, that advertises support for the .Net Standard 1.0 collection of libraries. Similar is true for .Net Standard 1.1, 1.5, 1.6, 2.0, etc. As long as the runtime provides support for the version of Standard targeted by your program, your program should run there.

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn't mean you can't take dependencies on other assemblies, or APIs published by other vendors (ie: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .Net Standard. .Net Standard is evolving quickly, but it's still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .Net Standard versions are much nicer and more full-featured).

On the other hand, an app targeted at Standard should be able to be used in more deployment situations, since in theory it can run with Core, Framework, Mono, etc. For a class library project looking for wide distribution, that's an attractive promise. For a class library project used mainly for internal purposes, it may not be as much of a concern.

.Net Standard can also be useful in situations where the SysAdmin team is wanting to move from ASP.Net on Windows to ASP.Net for .Net Core on Linux for philosophical or cost reasons, but the Development team wants to continue working against .Net Framework in Visual Studio on Windows.

share|improve this answer

edited Nov 3 '18 at 16:17

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  While a good overview of what .NET Core and .NET Standard are, this answer fails to answer the question about class libraries targeting each of these.
  
  – Gigi
  Mar 22 '17 at 8:17
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  If that's your goal, the question needs to be closed as either "unclear what you're asking", since there are always going to be too many situational specifics that play into a given person's environment for us to ever just tell you what to do, or as "Too Broad" if you're asking about the general case. All we can do here is give you info about the products, so you can be informed for making your own decision.
  
  – Joel Coehoorn
  May 1 '17 at 16:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is clearly not the case, as another has accurately answered the question. My question was about the class libraries. Your answer was about the frameworks.
  
  – Gigi
  May 2 '17 at 18:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JoelCoehoorn very technically explained.
  
  – BerBar
  Jan 2 at 3:18
  

  
  
  
  

add a comment | 

55

.Net Framework and .Net Core are two different implementations of the .Net runtime. Both Core and Framework (but especially Framework) have different profiles that include larger or smaller (or just plain different) selections of the many APIs and assemblies Microsoft has created for .Net, depending on where they are installed and in what profile. For example, there are some different APIs available in Universal Windows apps than in the "normal" Windows profile. Even on Windows, you might have the "Client" profile vs the "Full" profile. Additionally, there are other implementations (like Mono) that have their own sets of libraries.

.Net Standard is a specification for which sets of API libraries and assemblies must be available. An app written for .Net Standard 1.0 should be able to compile and run with any version of Framework, Core, Mono, etc, that advertises support for the .Net Standard 1.0 collection of libraries. Similar is true for .Net Standard 1.1, 1.5, 1.6, 2.0, etc. As long as the runtime provides support for the version of Standard targeted by your program, your program should run there.

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn't mean you can't take dependencies on other assemblies, or APIs published by other vendors (ie: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .Net Standard. .Net Standard is evolving quickly, but it's still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .Net Standard versions are much nicer and more full-featured).

On the other hand, an app targeted at Standard should be able to be used in more deployment situations, since in theory it can run with Core, Framework, Mono, etc. For a class library project looking for wide distribution, that's an attractive promise. For a class library project used mainly for internal purposes, it may not be as much of a concern.

.Net Standard can also be useful in situations where the SysAdmin team is wanting to move from ASP.Net on Windows to ASP.Net for .Net Core on Linux for philosophical or cost reasons, but the Development team wants to continue working against .Net Framework in Visual Studio on Windows.

share|improve this answer

edited Nov 3 '18 at 16:17

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  While a good overview of what .NET Core and .NET Standard are, this answer fails to answer the question about class libraries targeting each of these.
  
  – Gigi
  Mar 22 '17 at 8:17
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  If that's your goal, the question needs to be closed as either "unclear what you're asking", since there are always going to be too many situational specifics that play into a given person's environment for us to ever just tell you what to do, or as "Too Broad" if you're asking about the general case. All we can do here is give you info about the products, so you can be informed for making your own decision.
  
  – Joel Coehoorn
  May 1 '17 at 16:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is clearly not the case, as another has accurately answered the question. My question was about the class libraries. Your answer was about the frameworks.
  
  – Gigi
  May 2 '17 at 18:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JoelCoehoorn very technically explained.
  
  – BerBar
  Jan 2 at 3:18
  

  
  
  
  

add a comment | 

55

55

55

.Net Framework and .Net Core are two different implementations of the .Net runtime. Both Core and Framework (but especially Framework) have different profiles that include larger or smaller (or just plain different) selections of the many APIs and assemblies Microsoft has created for .Net, depending on where they are installed and in what profile. For example, there are some different APIs available in Universal Windows apps than in the "normal" Windows profile. Even on Windows, you might have the "Client" profile vs the "Full" profile. Additionally, there are other implementations (like Mono) that have their own sets of libraries.

.Net Standard is a specification for which sets of API libraries and assemblies must be available. An app written for .Net Standard 1.0 should be able to compile and run with any version of Framework, Core, Mono, etc, that advertises support for the .Net Standard 1.0 collection of libraries. Similar is true for .Net Standard 1.1, 1.5, 1.6, 2.0, etc. As long as the runtime provides support for the version of Standard targeted by your program, your program should run there.

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn't mean you can't take dependencies on other assemblies, or APIs published by other vendors (ie: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .Net Standard. .Net Standard is evolving quickly, but it's still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .Net Standard versions are much nicer and more full-featured).

On the other hand, an app targeted at Standard should be able to be used in more deployment situations, since in theory it can run with Core, Framework, Mono, etc. For a class library project looking for wide distribution, that's an attractive promise. For a class library project used mainly for internal purposes, it may not be as much of a concern.

.Net Standard can also be useful in situations where the SysAdmin team is wanting to move from ASP.Net on Windows to ASP.Net for .Net Core on Linux for philosophical or cost reasons, but the Development team wants to continue working against .Net Framework in Visual Studio on Windows.

share|improve this answer

edited Nov 3 '18 at 16:17

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

.Net Framework and .Net Core are two different implementations of the .Net runtime. Both Core and Framework (but especially Framework) have different profiles that include larger or smaller (or just plain different) selections of the many APIs and assemblies Microsoft has created for .Net, depending on where they are installed and in what profile. For example, there are some different APIs available in Universal Windows apps than in the "normal" Windows profile. Even on Windows, you might have the "Client" profile vs the "Full" profile. Additionally, there are other implementations (like Mono) that have their own sets of libraries.

.Net Standard is a specification for which sets of API libraries and assemblies must be available. An app written for .Net Standard 1.0 should be able to compile and run with any version of Framework, Core, Mono, etc, that advertises support for the .Net Standard 1.0 collection of libraries. Similar is true for .Net Standard 1.1, 1.5, 1.6, 2.0, etc. As long as the runtime provides support for the version of Standard targeted by your program, your program should run there.

A project targeted at a version of Standard will not be able to make use of features that are not included in that revision of the standard. This doesn't mean you can't take dependencies on other assemblies, or APIs published by other vendors (ie: items on NuGet). But it does mean that any dependencies you take must also include support for your version of .Net Standard. .Net Standard is evolving quickly, but it's still new enough, and cares enough about some of the smaller runtime profiles, that this limitation can feel stifling. (Note a year and a half later: this is starting to change, and recent .Net Standard versions are much nicer and more full-featured).

On the other hand, an app targeted at Standard should be able to be used in more deployment situations, since in theory it can run with Core, Framework, Mono, etc. For a class library project looking for wide distribution, that's an attractive promise. For a class library project used mainly for internal purposes, it may not be as much of a concern.

.Net Standard can also be useful in situations where the SysAdmin team is wanting to move from ASP.Net on Windows to ASP.Net for .Net Core on Linux for philosophical or cost reasons, but the Development team wants to continue working against .Net Framework in Visual Studio on Windows.

share|improve this answer

edited Nov 3 '18 at 16:17

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

share|improve this answer

share|improve this answer

edited Nov 3 '18 at 16:17

edited Nov 3 '18 at 16:17

edited Nov 3 '18 at 16:17

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

answered Mar 22 '17 at 0:42

Joel CoehoornJoel Coehoorn

310k96495730

310k96495730

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  While a good overview of what .NET Core and .NET Standard are, this answer fails to answer the question about class libraries targeting each of these.
  
  – Gigi
  Mar 22 '17 at 8:17
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  If that's your goal, the question needs to be closed as either "unclear what you're asking", since there are always going to be too many situational specifics that play into a given person's environment for us to ever just tell you what to do, or as "Too Broad" if you're asking about the general case. All we can do here is give you info about the products, so you can be informed for making your own decision.
  
  – Joel Coehoorn
  May 1 '17 at 16:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is clearly not the case, as another has accurately answered the question. My question was about the class libraries. Your answer was about the frameworks.
  
  – Gigi
  May 2 '17 at 18:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JoelCoehoorn very technically explained.
  
  – BerBar
  Jan 2 at 3:18
  

  
  
  
  

add a comment | 

• 
  
  
  

  
  1
  

  
  
  
  
  
  

  
  
  While a good overview of what .NET Core and .NET Standard are, this answer fails to answer the question about class libraries targeting each of these.
  
  – Gigi
  Mar 22 '17 at 8:17
  

  
  
  
  


• 
  
  
  

  
  5
  

  
  
  
  
  
  

  
  
  If that's your goal, the question needs to be closed as either "unclear what you're asking", since there are always going to be too many situational specifics that play into a given person's environment for us to ever just tell you what to do, or as "Too Broad" if you're asking about the general case. All we can do here is give you info about the products, so you can be informed for making your own decision.
  
  – Joel Coehoorn
  May 1 '17 at 16:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  That is clearly not the case, as another has accurately answered the question. My question was about the class libraries. Your answer was about the frameworks.
  
  – Gigi
  May 2 '17 at 18:28
  

  
  
  
  


• 
  
  
  

  
  

  
  
  
  
  
  

  
  
  @JoelCoehoorn very technically explained.
  
  – BerBar
  Jan 2 at 3:18
  

  
  
  
  

1

1

While a good overview of what .NET Core and .NET Standard are, this answer fails to answer the question about class libraries targeting each of these.

– Gigi
Mar 22 '17 at 8:17

While a good overview of what .NET Core and .NET Standard are, this answer fails to answer the question about class libraries targeting each of these.

– Gigi
Mar 22 '17 at 8:17

5

5

If that's your goal, the question needs to be closed as either "unclear what you're asking", since there are always going to be too many situational specifics that play into a given person's environment for us to ever just tell you what to do, or as "Too Broad" if you're asking about the general case. All we can do here is give you info about the products, so you can be informed for making your own decision.

– Joel Coehoorn
May 1 '17 at 16:28

If that's your goal, the question needs to be closed as either "unclear what you're asking", since there are always going to be too many situational specifics that play into a given person's environment for us to ever just tell you what to do, or as "Too Broad" if you're asking about the general case. All we can do here is give you info about the products, so you can be informed for making your own decision.

– Joel Coehoorn
May 1 '17 at 16:28

That is clearly not the case, as another has accurately answered the question. My question was about the class libraries. Your answer was about the frameworks.

– Gigi
May 2 '17 at 18:28

That is clearly not the case, as another has accurately answered the question. My question was about the class libraries. Your answer was about the frameworks.

– Gigi
May 2 '17 at 18:28

@JoelCoehoorn very technically explained.

– BerBar
Jan 2 at 3:18

@JoelCoehoorn very technically explained.

– BerBar
Jan 2 at 3:18

add a comment | 

12

.NET Framework and .NET Core are both frameworks.

.NET Standard is standard (in other words, specification).

You can make executable project (like Console application, or ASP.NET application) with .NET Framework and .NET Core, but not with .NET Standard.

With .NET Standard you can make only class-library project that cannot be executed standalone and should be referenced by another .NET Core or .NET Framework executable project.

share|improve this answer

answered Aug 8 '18 at 12:58

bsidebside

167210

add a comment | 

12

.NET Framework and .NET Core are both frameworks.

.NET Standard is standard (in other words, specification).

You can make executable project (like Console application, or ASP.NET application) with .NET Framework and .NET Core, but not with .NET Standard.

With .NET Standard you can make only class-library project that cannot be executed standalone and should be referenced by another .NET Core or .NET Framework executable project.

share|improve this answer

answered Aug 8 '18 at 12:58

bsidebside

167210

add a comment | 

12

12

12

.NET Framework and .NET Core are both frameworks.

.NET Standard is standard (in other words, specification).

You can make executable project (like Console application, or ASP.NET application) with .NET Framework and .NET Core, but not with .NET Standard.

With .NET Standard you can make only class-library project that cannot be executed standalone and should be referenced by another .NET Core or .NET Framework executable project.

share|improve this answer

answered Aug 8 '18 at 12:58

bsidebside

167210

.NET Framework and .NET Core are both frameworks.

.NET Standard is standard (in other words, specification).

You can make executable project (like Console application, or ASP.NET application) with .NET Framework and .NET Core, but not with .NET Standard.

With .NET Standard you can make only class-library project that cannot be executed standalone and should be referenced by another .NET Core or .NET Framework executable project.

share|improve this answer

answered Aug 8 '18 at 12:58

bsidebside

167210

share|improve this answer

share|improve this answer

answered Aug 8 '18 at 12:58

bsidebside

167210

answered Aug 8 '18 at 12:58

bsidebside

167210

answered Aug 8 '18 at 12:58

bsidebside

167210

167210

add a comment | 

add a comment | 

7

.NET Standard: Think of it as a big standard library. When using this as a dependency you can only make libraries (.DLLs), not executables. A library made with .NET standard as a dependency can be added to a Xamarin.Android, a Xamarin.iOS, a .NET Core Windows/OSX/Linux project.

.NET Core: Think of it as the continuation of the old .NET framework, just it's opensource and some stuff is not yet implemented and others got deprecated. It extends the .NET standard with extra functions, but only runs on Desktops. When adding this as a dependency you can make runnable apps on Windows, Linux and OSX. (Although console only for now, no GUIs). So .NET Core = .NET Standard + Desktop specific stuff.

Also UWP uses it and the new ASP.NET core uses it as a dependency too.

share|improve this answer

answered Dec 26 '17 at 3:45

community wiki

sydd

add a comment | 

7

.NET Standard: Think of it as a big standard library. When using this as a dependency you can only make libraries (.DLLs), not executables. A library made with .NET standard as a dependency can be added to a Xamarin.Android, a Xamarin.iOS, a .NET Core Windows/OSX/Linux project.

.NET Core: Think of it as the continuation of the old .NET framework, just it's opensource and some stuff is not yet implemented and others got deprecated. It extends the .NET standard with extra functions, but only runs on Desktops. When adding this as a dependency you can make runnable apps on Windows, Linux and OSX. (Although console only for now, no GUIs). So .NET Core = .NET Standard + Desktop specific stuff.

Also UWP uses it and the new ASP.NET core uses it as a dependency too.

share|improve this answer

answered Dec 26 '17 at 3:45

community wiki

sydd

add a comment | 

7

7

7

.NET Standard: Think of it as a big standard library. When using this as a dependency you can only make libraries (.DLLs), not executables. A library made with .NET standard as a dependency can be added to a Xamarin.Android, a Xamarin.iOS, a .NET Core Windows/OSX/Linux project.

.NET Core: Think of it as the continuation of the old .NET framework, just it's opensource and some stuff is not yet implemented and others got deprecated. It extends the .NET standard with extra functions, but only runs on Desktops. When adding this as a dependency you can make runnable apps on Windows, Linux and OSX. (Although console only for now, no GUIs). So .NET Core = .NET Standard + Desktop specific stuff.

Also UWP uses it and the new ASP.NET core uses it as a dependency too.

share|improve this answer

answered Dec 26 '17 at 3:45

community wiki

sydd

.NET Standard: Think of it as a big standard library. When using this as a dependency you can only make libraries (.DLLs), not executables. A library made with .NET standard as a dependency can be added to a Xamarin.Android, a Xamarin.iOS, a .NET Core Windows/OSX/Linux project.

.NET Core: Think of it as the continuation of the old .NET framework, just it's opensource and some stuff is not yet implemented and others got deprecated. It extends the .NET standard with extra functions, but only runs on Desktops. When adding this as a dependency you can make runnable apps on Windows, Linux and OSX. (Although console only for now, no GUIs). So .NET Core = .NET Standard + Desktop specific stuff.

Also UWP uses it and the new ASP.NET core uses it as a dependency too.

share|improve this answer

answered Dec 26 '17 at 3:45

community wiki

sydd

share|improve this answer

share|improve this answer

answered Dec 26 '17 at 3:45

answered Dec 26 '17 at 3:45

answered Dec 26 '17 at 3:45

community wiki

sydd

community wiki

sydd

community wiki

sydd

add a comment | 

add a comment | 

7

Hope this will help to understand the relationship between .NET Standard API surface and other .NET platforms. Each interface represents a target framework and methods represents groups of APIs available on that target framework.

namespace Analogy

{

  // .NET Standard



interface INetStandard10

{

    void Primitives();

    void Reflection();

    void Tasks();

    void Xml();

    void Collections();

    void Linq();

}



interface INetStandard11 : INetStandard10

{

    void ConcurrentCollections();

    void LinqParallel();

    void Compression();

    void HttpClient();

}



interface INetStandard12 : INetStandard11

{

    void ThreadingTimer();

}



interface INetStandard13 : INetStandard12

{

    //.NET Standard 1.3 specific APIs

}



// And so on ...





// .NET Framework 



interface INetFramework45 : INetStandard11

{

    void FileSystem();

    void Console();

    void ThreadPool();

    void Crypto();

    void WebSockets();

    void Process();

    void Drawing();

    void SystemWeb();

    void WPF();

    void WindowsForms();

    void WCF();

}



interface INetFramework451 : INetFramework45, INetStandard12

{

    // .NET Framework 4.5.1 specific APIs

}



interface INetFramework452 : INetFramework451, INetStandard12

{

    // .NET Framework 4.5.2 specific APIs

}



interface INetFramework46 : INetFramework452, INetStandard13

{

    // .NET Framework 4.6 specific APIs

}



interface INetFramework461 : INetFramework46, INetStandard14

{

    // .NET Framework 4.6.1 specific APIs

}



interface INetFramework462 : INetFramework461, INetStandard15

{

    // .NET Framework 4.6.2 specific APIs

}



// .NET Core

interface INetCoreApp10 : INetStandard15

{

    // TODO: .NET Core 1.0 specific APIs

}

// Windows Universal Platform

interface IWindowsUniversalPlatform : INetStandard13

{

    void GPS();

    void Xaml();

}



// Xamarin 

interface IXamarinIOS : INetStandard15

{

    void AppleAPIs();

}



interface IXamarinAndroid : INetStandard15

{

    void GoogleAPIs();

}    

// Future platform



interface ISomeFuturePlatform : INetStandard13

{

    // A future platform chooses to implement a specific .NET Standard version.

    // All libraries that target that version are instantly compatible with this new

    // platform

}

}

Source

share|improve this answer

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

add a comment | 

7

Hope this will help to understand the relationship between .NET Standard API surface and other .NET platforms. Each interface represents a target framework and methods represents groups of APIs available on that target framework.

namespace Analogy

{

  // .NET Standard



interface INetStandard10

{

    void Primitives();

    void Reflection();

    void Tasks();

    void Xml();

    void Collections();

    void Linq();

}



interface INetStandard11 : INetStandard10

{

    void ConcurrentCollections();

    void LinqParallel();

    void Compression();

    void HttpClient();

}



interface INetStandard12 : INetStandard11

{

    void ThreadingTimer();

}



interface INetStandard13 : INetStandard12

{

    //.NET Standard 1.3 specific APIs

}



// And so on ...





// .NET Framework 



interface INetFramework45 : INetStandard11

{

    void FileSystem();

    void Console();

    void ThreadPool();

    void Crypto();

    void WebSockets();

    void Process();

    void Drawing();

    void SystemWeb();

    void WPF();

    void WindowsForms();

    void WCF();

}



interface INetFramework451 : INetFramework45, INetStandard12

{

    // .NET Framework 4.5.1 specific APIs

}



interface INetFramework452 : INetFramework451, INetStandard12

{

    // .NET Framework 4.5.2 specific APIs

}



interface INetFramework46 : INetFramework452, INetStandard13

{

    // .NET Framework 4.6 specific APIs

}



interface INetFramework461 : INetFramework46, INetStandard14

{

    // .NET Framework 4.6.1 specific APIs

}



interface INetFramework462 : INetFramework461, INetStandard15

{

    // .NET Framework 4.6.2 specific APIs

}



// .NET Core

interface INetCoreApp10 : INetStandard15

{

    // TODO: .NET Core 1.0 specific APIs

}

// Windows Universal Platform

interface IWindowsUniversalPlatform : INetStandard13

{

    void GPS();

    void Xaml();

}



// Xamarin 

interface IXamarinIOS : INetStandard15

{

    void AppleAPIs();

}



interface IXamarinAndroid : INetStandard15

{

    void GoogleAPIs();

}    

// Future platform



interface ISomeFuturePlatform : INetStandard13

{

    // A future platform chooses to implement a specific .NET Standard version.

    // All libraries that target that version are instantly compatible with this new

    // platform

}

}

Source

share|improve this answer

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

add a comment | 

7

7

7

Hope this will help to understand the relationship between .NET Standard API surface and other .NET platforms. Each interface represents a target framework and methods represents groups of APIs available on that target framework.

namespace Analogy

{

  // .NET Standard



interface INetStandard10

{

    void Primitives();

    void Reflection();

    void Tasks();

    void Xml();

    void Collections();

    void Linq();

}



interface INetStandard11 : INetStandard10

{

    void ConcurrentCollections();

    void LinqParallel();

    void Compression();

    void HttpClient();

}



interface INetStandard12 : INetStandard11

{

    void ThreadingTimer();

}



interface INetStandard13 : INetStandard12

{

    //.NET Standard 1.3 specific APIs

}



// And so on ...





// .NET Framework 



interface INetFramework45 : INetStandard11

{

    void FileSystem();

    void Console();

    void ThreadPool();

    void Crypto();

    void WebSockets();

    void Process();

    void Drawing();

    void SystemWeb();

    void WPF();

    void WindowsForms();

    void WCF();

}



interface INetFramework451 : INetFramework45, INetStandard12

{

    // .NET Framework 4.5.1 specific APIs

}



interface INetFramework452 : INetFramework451, INetStandard12

{

    // .NET Framework 4.5.2 specific APIs

}



interface INetFramework46 : INetFramework452, INetStandard13

{

    // .NET Framework 4.6 specific APIs

}



interface INetFramework461 : INetFramework46, INetStandard14

{

    // .NET Framework 4.6.1 specific APIs

}



interface INetFramework462 : INetFramework461, INetStandard15

{

    // .NET Framework 4.6.2 specific APIs

}



// .NET Core

interface INetCoreApp10 : INetStandard15

{

    // TODO: .NET Core 1.0 specific APIs

}

// Windows Universal Platform

interface IWindowsUniversalPlatform : INetStandard13

{

    void GPS();

    void Xaml();

}



// Xamarin 

interface IXamarinIOS : INetStandard15

{

    void AppleAPIs();

}



interface IXamarinAndroid : INetStandard15

{

    void GoogleAPIs();

}    

// Future platform



interface ISomeFuturePlatform : INetStandard13

{

    // A future platform chooses to implement a specific .NET Standard version.

    // All libraries that target that version are instantly compatible with this new

    // platform

}

}

Source

share|improve this answer

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

Hope this will help to understand the relationship between .NET Standard API surface and other .NET platforms. Each interface represents a target framework and methods represents groups of APIs available on that target framework.

namespace Analogy

{

  // .NET Standard



interface INetStandard10

{

    void Primitives();

    void Reflection();

    void Tasks();

    void Xml();

    void Collections();

    void Linq();

}



interface INetStandard11 : INetStandard10

{

    void ConcurrentCollections();

    void LinqParallel();

    void Compression();

    void HttpClient();

}



interface INetStandard12 : INetStandard11

{

    void ThreadingTimer();

}



interface INetStandard13 : INetStandard12

{

    //.NET Standard 1.3 specific APIs

}



// And so on ...





// .NET Framework 



interface INetFramework45 : INetStandard11

{

    void FileSystem();

    void Console();

    void ThreadPool();

    void Crypto();

    void WebSockets();

    void Process();

    void Drawing();

    void SystemWeb();

    void WPF();

    void WindowsForms();

    void WCF();

}



interface INetFramework451 : INetFramework45, INetStandard12

{

    // .NET Framework 4.5.1 specific APIs

}



interface INetFramework452 : INetFramework451, INetStandard12

{

    // .NET Framework 4.5.2 specific APIs

}



interface INetFramework46 : INetFramework452, INetStandard13

{

    // .NET Framework 4.6 specific APIs

}



interface INetFramework461 : INetFramework46, INetStandard14

{

    // .NET Framework 4.6.1 specific APIs

}



interface INetFramework462 : INetFramework461, INetStandard15

{

    // .NET Framework 4.6.2 specific APIs

}



// .NET Core

interface INetCoreApp10 : INetStandard15

{

    // TODO: .NET Core 1.0 specific APIs

}

// Windows Universal Platform

interface IWindowsUniversalPlatform : INetStandard13

{

    void GPS();

    void Xaml();

}



// Xamarin 

interface IXamarinIOS : INetStandard15

{

    void AppleAPIs();

}



interface IXamarinAndroid : INetStandard15

{

    void GoogleAPIs();

}    

// Future platform



interface ISomeFuturePlatform : INetStandard13

{

    // A future platform chooses to implement a specific .NET Standard version.

    // All libraries that target that version are instantly compatible with this new

    // platform

}

}

Source

share|improve this answer

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

share|improve this answer

share|improve this answer

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

answered Sep 1 '18 at 13:28

Mahbubur RahmanMahbubur Rahman

2,7891830

2,7891830

add a comment | 

add a comment | 

5

.Net Standard exists mainly to improve code sharing and make the APIs available in each .Net implementation more consistent.

While creating Libraries we can have target as.Net Standard 2.0 so that the library created would be compaitible with different versions of .Net Framework including .Net Core,Mono..

share|improve this answer

answered Aug 15 '17 at 15:50

ARPARP

5111

add a comment | 

5

.Net Standard exists mainly to improve code sharing and make the APIs available in each .Net implementation more consistent.

While creating Libraries we can have target as.Net Standard 2.0 so that the library created would be compaitible with different versions of .Net Framework including .Net Core,Mono..

share|improve this answer

answered Aug 15 '17 at 15:50

ARPARP

5111

add a comment | 

5

5

5

.Net Standard exists mainly to improve code sharing and make the APIs available in each .Net implementation more consistent.

While creating Libraries we can have target as.Net Standard 2.0 so that the library created would be compaitible with different versions of .Net Framework including .Net Core,Mono..

share|improve this answer

answered Aug 15 '17 at 15:50

ARPARP

5111

.Net Standard exists mainly to improve code sharing and make the APIs available in each .Net implementation more consistent.

While creating Libraries we can have target as.Net Standard 2.0 so that the library created would be compaitible with different versions of .Net Framework including .Net Core,Mono..

share|improve this answer

answered Aug 15 '17 at 15:50

ARPARP

5111

share|improve this answer

share|improve this answer

answered Aug 15 '17 at 15:50

ARPARP

5111

answered Aug 15 '17 at 15:50

ARPARP

5111

answered Aug 15 '17 at 15:50

ARPARP

5111

5111

add a comment | 

add a comment | 

2

Another way of explaining the difference could be with real world examples, as most of us mortals will use existing tools and frameworks (Xamarin, Unity, etc) to do the job.

So, with .NET Framework you have all the .NET tools to work with but you can only target Windows applications (UWP, Winforms, ASP.NET, etc). Since .NET Framework is closed source there isn't much to do about it.

With .NET Core you have less tools but you can target the main Desktop Platforms (Windows, Linux, Mac). This is specially useful in ASP.NET Core applications, since you can now host Asp.net in Linux (cheaper hosting prices). Now, since .NET Core was open sourced, it's technically possible to develop libraries for other platforms. But since there aren't frameworks that support it, i don't think that's a good idea.

With .NET Standard you have even less tools but you can target all/most platforms. You can target Mobile thanks to Xamarin, and you can even target Game Consoles thanks to Mono/Unity.

In a real world application you may need to use all of them. For example, i developed a point of sale application that had the following architecture:

Shared both Server and Client:

• A .NET Standard library that handles the Models of my application.

Since it's a .NET Standard library, it can be used in any other library.

Server Side (Web API):

• A .NET Standard (could be Core as well) library that handles all the
  database connections.




• A .NET Core project that handles the Rest API and makes use of the
  database library.

As this is developed in .NET Core, i can host the application on a Linux server.

Client Side (MVVM with WPF + Xamarin.Forms Android/IOS):

• A .NET Standard library that handles the client API connection.




• A .NET Standard library that handles the ViewModels Logic. Used in
  all the views.




• A .NET Framework WPF application that handles the WPF views for a
  windows application.




• A .NET Standard library that handles Xamarin Forms views.




• A Xamarin Android and Xamarin IOS project.

So you can see that there's a big advantage here in the client side of the application since i can reuse both .NET Standard libraries (Client API and ViewModels) and just make views with no logic for the WPF, Xamarin and IOS applications.

share|improve this answer

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

add a comment | 

2

Another way of explaining the difference could be with real world examples, as most of us mortals will use existing tools and frameworks (Xamarin, Unity, etc) to do the job.

So, with .NET Framework you have all the .NET tools to work with but you can only target Windows applications (UWP, Winforms, ASP.NET, etc). Since .NET Framework is closed source there isn't much to do about it.

With .NET Core you have less tools but you can target the main Desktop Platforms (Windows, Linux, Mac). This is specially useful in ASP.NET Core applications, since you can now host Asp.net in Linux (cheaper hosting prices). Now, since .NET Core was open sourced, it's technically possible to develop libraries for other platforms. But since there aren't frameworks that support it, i don't think that's a good idea.

With .NET Standard you have even less tools but you can target all/most platforms. You can target Mobile thanks to Xamarin, and you can even target Game Consoles thanks to Mono/Unity.

In a real world application you may need to use all of them. For example, i developed a point of sale application that had the following architecture:

Shared both Server and Client:

• A .NET Standard library that handles the Models of my application.

Since it's a .NET Standard library, it can be used in any other library.

Server Side (Web API):

• A .NET Standard (could be Core as well) library that handles all the
  database connections.




• A .NET Core project that handles the Rest API and makes use of the
  database library.

As this is developed in .NET Core, i can host the application on a Linux server.

Client Side (MVVM with WPF + Xamarin.Forms Android/IOS):

• A .NET Standard library that handles the client API connection.




• A .NET Standard library that handles the ViewModels Logic. Used in
  all the views.




• A .NET Framework WPF application that handles the WPF views for a
  windows application.




• A .NET Standard library that handles Xamarin Forms views.




• A Xamarin Android and Xamarin IOS project.

So you can see that there's a big advantage here in the client side of the application since i can reuse both .NET Standard libraries (Client API and ViewModels) and just make views with no logic for the WPF, Xamarin and IOS applications.

share|improve this answer

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

add a comment | 

2

2

2

Another way of explaining the difference could be with real world examples, as most of us mortals will use existing tools and frameworks (Xamarin, Unity, etc) to do the job.

So, with .NET Framework you have all the .NET tools to work with but you can only target Windows applications (UWP, Winforms, ASP.NET, etc). Since .NET Framework is closed source there isn't much to do about it.

With .NET Core you have less tools but you can target the main Desktop Platforms (Windows, Linux, Mac). This is specially useful in ASP.NET Core applications, since you can now host Asp.net in Linux (cheaper hosting prices). Now, since .NET Core was open sourced, it's technically possible to develop libraries for other platforms. But since there aren't frameworks that support it, i don't think that's a good idea.

With .NET Standard you have even less tools but you can target all/most platforms. You can target Mobile thanks to Xamarin, and you can even target Game Consoles thanks to Mono/Unity.

In a real world application you may need to use all of them. For example, i developed a point of sale application that had the following architecture:

Shared both Server and Client:

• A .NET Standard library that handles the Models of my application.

Since it's a .NET Standard library, it can be used in any other library.

Server Side (Web API):

• A .NET Standard (could be Core as well) library that handles all the
  database connections.




• A .NET Core project that handles the Rest API and makes use of the
  database library.

As this is developed in .NET Core, i can host the application on a Linux server.

Client Side (MVVM with WPF + Xamarin.Forms Android/IOS):

• A .NET Standard library that handles the client API connection.




• A .NET Standard library that handles the ViewModels Logic. Used in
  all the views.




• A .NET Framework WPF application that handles the WPF views for a
  windows application.




• A .NET Standard library that handles Xamarin Forms views.




• A Xamarin Android and Xamarin IOS project.

So you can see that there's a big advantage here in the client side of the application since i can reuse both .NET Standard libraries (Client API and ViewModels) and just make views with no logic for the WPF, Xamarin and IOS applications.

share|improve this answer

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

Another way of explaining the difference could be with real world examples, as most of us mortals will use existing tools and frameworks (Xamarin, Unity, etc) to do the job.

So, with .NET Framework you have all the .NET tools to work with but you can only target Windows applications (UWP, Winforms, ASP.NET, etc). Since .NET Framework is closed source there isn't much to do about it.

With .NET Core you have less tools but you can target the main Desktop Platforms (Windows, Linux, Mac). This is specially useful in ASP.NET Core applications, since you can now host Asp.net in Linux (cheaper hosting prices). Now, since .NET Core was open sourced, it's technically possible to develop libraries for other platforms. But since there aren't frameworks that support it, i don't think that's a good idea.

With .NET Standard you have even less tools but you can target all/most platforms. You can target Mobile thanks to Xamarin, and you can even target Game Consoles thanks to Mono/Unity.

In a real world application you may need to use all of them. For example, i developed a point of sale application that had the following architecture:

Shared both Server and Client:

• A .NET Standard library that handles the Models of my application.

Since it's a .NET Standard library, it can be used in any other library.

Server Side (Web API):

• A .NET Standard (could be Core as well) library that handles all the
  database connections.




• A .NET Core project that handles the Rest API and makes use of the
  database library.

As this is developed in .NET Core, i can host the application on a Linux server.

Client Side (MVVM with WPF + Xamarin.Forms Android/IOS):

• A .NET Standard library that handles the client API connection.




• A .NET Standard library that handles the ViewModels Logic. Used in
  all the views.




• A .NET Framework WPF application that handles the WPF views for a
  windows application.




• A .NET Standard library that handles Xamarin Forms views.




• A Xamarin Android and Xamarin IOS project.

So you can see that there's a big advantage here in the client side of the application since i can reuse both .NET Standard libraries (Client API and ViewModels) and just make views with no logic for the WPF, Xamarin and IOS applications.

share|improve this answer

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

share|improve this answer

share|improve this answer

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

answered Dec 10 '18 at 19:56

Dev KevinDev Kevin

412

412

add a comment | 

add a comment | 

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question. Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.


• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Thanks for contributing an answer to Stack Overflow!

• Please be sure to answer the question. Provide details and share your research!

But avoid …

• Asking for help, clarification, or responding to other answers.


• Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers.

draft saved

draft discarded

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f42939454%2fwhat-is-the-difference-between-net-core-and-net-standard-class-library-project%23new-answer', 'question_page');
}
);

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Sign up or log in

StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Sign up using Google

Sign up using Facebook

Sign up using Email and Password

Post as a guest

Name

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Name

Name

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

Email

Required, but never shown

This page is only for reference, If you need detailed information, please check here