16

I'm still pretty confused about how .NET Core and .NET Standard relate to each other.

From what I understand, .NET Standard is an interface definition (not dissimilar in the way the Katana is an implementation of OWIN). .NET Framework will implement versions of .NET Standard.

Is this correct so far?

.NET Core bundles up its dependencies inside it. Those dependencies will use the .NET Standard interface's implementation. That may be the .NET Framework, Mono or something else.

ASP Core is .NET Core with "Web" stuff referenced. Pretty much just a Visual Studio template in the sense that it can all by built up from a .NET Core console application.

Am I still close to on track?

Finally, if I can creating a new, green-field application then .NET Core should be the favoured technology (assuming that I don't need any of the .NET Framework only assemblies).

Last question, can I reference .NET Framework assemblies in the GAC from a .NET Core project?

Cheers

BanksySan
  • 27,362
  • 33
  • 117
  • 216
  • Good question, I'm somehow still confused about a few parts myself. But yeah, the first part is correct .NET Standard is a specification of APIs, which ensures compatibility. – jAC Jun 19 '17 at 19:51
  • @JanesAbouChleih Off to a good start then. Is .NET Core an implementation of .NET Standard then? – BanksySan Jun 19 '17 at 19:52
  • 1
    Yes, I believe so. It builds upon .NET Standard. E.g. .NET Core 2.0 is built upon .NET Standard 2.0 and so on, .NET Core 1.0 is built upon NET Standard 1.6, and so on. I think there's already a question regarding this... searching. Found it: https://stackoverflow.com/questions/44085424/net-standard-vs-net-core – jAC Jun 19 '17 at 19:54
  • "Can I reference .NET Framework assemblies in the GAC from a .NET Core project?" If you do, your project ceases to actually be .NET Core, and can "merely" run on .NET Framework. So yes, but don't, since it's never what you actually want to do. – Jeroen Mostert Jun 19 '17 at 19:59
  • @JeroenMostert Aye, I realise that would bind it to the framework. – BanksySan Jun 19 '17 at 20:00
  • The worse part is that pulling in random .NET Framework assemblies means you wouldn't be adhering to whatever .NET Standard version you are claiming to target either. It's fairly easy to get a frankenbuild like that to actually work (locally), but without it running on a clean .NET Core installation (no Linux for you!) – Jeroen Mostert Jun 19 '17 at 20:04
  • @JeroenMostert I wasn't planning on it, just wanted to know what my options would be. – BanksySan Jun 19 '17 at 20:06
  • I only mention it because this is probably the most common mistake made by new developers: they want to go .NET Core because it's hip and new, then they discover some missing dependency they need that's not in .NET Standard 1.x, shoehorn in a framework assembly to get things working, and hey presto, you've got the worst of both worlds! It is possible to make a build that will work cleanly for any .NET Standard platform, but it requires a bit of attention. Later versions of .NET Standard cover more, so it's less of an issue. – Jeroen Mostert Jun 19 '17 at 20:09
  • @JeroenMostert I was asking so I had a bolt hole if it was needed. If I want to play with Core I need to know I have a quick and simple escape plan. – BanksySan Jun 19 '17 at 20:11
  • For brand new work, [pick the highest .NET Standard version matching all the platforms you're willing to "demand"](https://docs.microsoft.com/en-us/dotnet/standard/library) (1.6 is a good choice at the time of writing) and the rest should fall into place easily. You can then make a build that works on both Core and Platform. Should you still have functionality that works only on .NET Platform, you can do platform-specific references (and you must then work around this for Core somehow, like stubbing out things with `#if`). A build that can target Framework will allow you to bolt as needed. – Jeroen Mostert Jun 19 '17 at 20:17
  • Great, thanks, @JeroenMostert. Do you want to put that as a real answer? – BanksySan Jun 19 '17 at 20:18
  • Not really, I still only have one "port" to .NET Standard under my belt (though that was a particularly challenging one). But see [this question](https://stackoverflow.com/questions/40514546/difference-between-net-core-portable-standard-compact-uwp-and-pcl/), which also has an answer from me. It's a bit more extensive than you need for *your* purposes, however. – Jeroen Mostert Jun 19 '17 at 20:21
  • This link helped me a lot: https://weblog.west-wind.com/posts/2016/Nov/23/NET-Standard-20-Making-Sense-of-NET-Again – jpgrassi Jun 19 '17 at 20:39
  • See also https://www.hanselman.com/blog/HowToReferenceANETCoreLibraryInWinFormsOrNETStandardExplained.aspx – Uwe Keim Jun 19 '17 at 20:46
  • You shouldn't be referencing assemblies in the GAC at all. If you wish to reference "full" .NET Framework assemblies, you should be using the reference assemblies installed under `Program Files (x86)\Reference Assemblies` subdirectories by various SDK installers. The GAC is only meant to be used at *runtime*, not *build* time. – Damien_The_Unbeliever Jun 20 '17 at 05:48

4 Answers4

11

My understanding is that the .NET Core is implementing the .NET Standard.

So .NET Standard is more like a specification and .NET Core is an actual framework which implements that specification.

.NET Standard is also implemented by other frameworks like as .NET Framework or Xamarin (and ASP.NET Core which is built on the top of .NET Core).


Here is offficial explanation:

How is .NET Standard different from .NET Core?

.NET Standard is a specification that covers which APIs a .NET platform has to implement.

.NET Core is a concrete .NET platform and implements the .NET Standard.


.NET Standard:

The .NET Standard is a formal specification of .NET APIs that are intended to be available on all .NET runtimes.

The various .NET runtimes implement specific versions of .NET Standard.


Introducing .NET Standard:

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

.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.


Introducing .NET Core:

.NET Core is essentially a fork of the NET Framework

Another way to look at it: The .NET Framework has essentially two forks. One fork is provided by Microsoft and is Windows only. The other fork is Mono which you can use on Linux and Mac.


For more details please read:

Lukasz Mk
  • 7,000
  • 2
  • 27
  • 41
7
  1. Yes, .NET Core is a platform / runtime that implements a version of .NET Standard.

If you build a library that targets a version of .NET Standard, it can be used on any runtime that implements this or a higher version of .NET Standard. This applies to .NET Core as well as mono (=> Xamarin), UWP (.NET Native) and .NET Framework.

  1. The detail of distribution doesn't really matter.. technically .NET Core < 2.0 relies on the way NETStandard.Library is built but that is changing for 2.0.

  2. ASP.NET Core is "just" a set of libraries and tooling atop a version of .NET Standard (pre 2.0 also a version of .NET Framework) that it requires to run on. This means you can build ASP.NET Core applications for both .NET Core and .NET Framework - potentially even other runtimes if they support the required level of .NET Standard.

  3. For new projects, it makes sense to evaluate what your needs are. .NET Core has a different servicing policy than .NET Framework and .NET Framework still has components and API that aren't going to be included in .NET Core - for example WinForms and WPF.

    For new library projects, it makes sense to target .NET Standard instead of .NET Framework wherever possible to ensure reusability in more types of projects.

Community
  • 1
  • 1
Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
4

Simple answer is yes:

.NET Core implements the .NET Standard Library, and therefore supports .NET Standard Libraries.

And ASP.NET Core built on .NET Core.

But: this does not mean that all ASP.NET Core apps support .NET Standard. ASP.NET Core apps can run on .NET Core or on the full .NET Framework. If an app has the full .NET Framework as a target platform it may have dependencies on libraries, that don't support .NET Standard.

BanksySan
  • 27,362
  • 33
  • 117
  • 216
Set
  • 47,577
  • 22
  • 132
  • 150
3

The other answers are great and cover the how, but I think the key to really understanding .NET Standard is the why.

What is .NET Standard actually for?

The purpose of .NET Standard is to allow developers to write their library and general purpose code in such a way that it can then be used by any applications they write, no matter which platform the application using that code targets (web, desktop, mobile, service etc.).

This is needed because .NET has forked and evolved into many flavours (principally full .NET Framework, .NET Core and Xamarin). Currently, if you want to write some code that encapsulates for example, some key business logic, and then use that code in both the desktop app, the mobile app and the website then that is difficult to achieve.

Write once, run anywhere

The idea of .NET Standard is that if you write your code to target just the APIs in .NET Standard, then it should work on any platform that has a version of .NET installed that implements the .NET Standard.

You don't write your whole app in .NET Standard, because you will still need platform or .NET version specific features (such as windows forms control libraries, Xamarin forms controls, file system access, web security, etc.), but if you write your library code to target .NET Standard you'll know that it can be easily shared between different apps on different platforms and that it should work on those platforms if they have a .NET Standard implementing version of .NET installed.

The ["Why do we need a standard?" section of this MSDN blog by Immo Landewerth][1] covers this well.

tomRedox
  • 28,092
  • 24
  • 117
  • 154