Scott Hanselman

While I can't offer any constructive critiques, I can say that this will be a very good teaching/learning tool, especially for visual learners like myself.

We should have CGP Grey do an explainer.

This is great. A very nice follow up, once you're done, would be: how to answer to those questions.
You know, just to be sure everything is crystal clear.

Is there a need to specify that an app written against a given .net standard version will run on every device that supports that standard? May be use your apple watch, raspberry pi analogy. Can't phrase it correctly - hope you get the gist.

Hmm, this is a good diagram. I feel like I have been drawing a crude version of this at work for explanations. Glad you included F# =).

Feedback wise:
More color contrast in the boxes might be an improvement. May be hard to see for color blind.

The items in the blue boxes, the way they are in separate boxes may confuse a user into thinking that C# does not have a any relation to CLR or the .NET SDK.

Come to think of it, it won't just run, will have to be published against each runtime.

CLR/CoreCLR – “Which runtime is your app using?”

An implementation of .NET is a runtime along with libraries that implement a version of the .NET Standard

Maybe the overlap can be visually represented? Or the CLR/CoreCLR brought down into the box below and show sub-boxes for CLR/CoreCLR, BCK etc.

I'll agree with others and say the colors need more contrast. I'd also take the language box out- the languages are kind of orthogonal to this whole thing.

CodeMonkey: See this slide, Boss- it explains what .NET Standard means.
Boss: Oh, ok great! Where do our Silverlight applications fit in?
CodeMonkey: ...

Looks good to me, though I'll second the comments on contrast (esp. between 2nd and 3rd boxes).

One thought: it may not be important enough for your goal here, but I might separate the platform layer into OS and hardware (get people to recognize they aren't in lockstep).

What's the name for the new, smaller XML project files? I refer to them as .Net SDK projects, but I don't know if that's accurate.

I love this, great visual. In thinking about this, I feel like I have seen this as a slide countless times (or something similar to it). And now there is a pseudo legend / glossary I feel like it should be interactive. I could imagine this living on the docs site, and as a user I could interact with this visual. And it would evolve over time. I could click on an area and get a flyout for example, with various details. Information or links to more docs, or examples... If I clicked on ".NET SDK" imagine a popup (or pick your favorite UX) and it would tell me immediately as a developer what it means, and provide examples. Here are some SDKs, I'd think to myself "oh, I know what they mean by this now".

I'm not sure what this is telling me overall... but the way I interpret it ( as a narrative )

There's layers

Application Framework is built on top of
Metapackage, which is built on top of (does it have to be built on top of a meta package?)
a .net runtime, with libraries that implement a version of the .NET standard (Problem: not everything is .NET standard?)
which is built on an Operating System

A MetaPackage is made up of Nuget packages? whys there a / inbetween package and nuget?
nuget packages is made up of libraries/assembly... what's with the / again??
a library consists of possibly ".NET standard", a lanaguage? some sdk? and clr/coreCLR ( now the / implies a OR condition... not quite sure the previous /s mean OR)

Hold on, a library doesn't contain C#/F#/VB, that's independent... I guess he's trying to imply it's source is written in one of those languages? seems an odd way to represent this.... actually at this level everything seems off, a library uses a language to target the other two things. actually, the sdk isn't a thing, it's a set of tools..... now I'm really not sure what this whole box is trying to say.

whys .net standard out on its own? that also has language? yeah...... really not sure what the diagram is trying to communicate? Yet I build shit with all these tools all the time, they are all things I know, but I'm not sure what useful relationship is getting communicated between these things?

Can you illustrate how original .NET incarnations fit here, for example, which question do I answer with "I used .NET v4.6.2 for this"?

I see at least 3 separate concerns here:

• Authoring - languages, SDK, .NET Standard, Application Framework -> assembly
  
• Execution - assembly -> runtimes, platform
  
• Sharing - assembly -> package, metapackage
  

I feel it would be really helpful if the distinction was clear and it would also give an opportunity to show exactly how they relate to each other.

Scott I agree with the comments about the contrast.

Have you considered running the image through a colour blind simulator like this one? - http://www.color-blindness.com/coblis-color-blindness-simulator/

Vischeck is also a good tool to play with - http://www.vischeck.com/

Scott, I think something like this is absolutely needed.

It feels like I woke up one morning and suddenly just saying I was developing a .NET application wasn't enough any more. Seemingly overnight (maybe I just wasn't paying enough attention) we all need to be a lot more specific and precise in the language we use.

Whilst this is a small price to pay for all the new options we have in front of us, a glossary is now absolutely essential.

The only suggestion I'd make is that I'm not sure the nesting feels that intuitive. At least, it doesn't match my mental model. To me it feels more like a scale than a hierarchy.

Anyway, keep up the great work.

Thanks for this very useful, visual map.

My initial reaction was to question the ".Net Standard" box - does this really sit here? Or should it be more like several boxes labelled ".Net Core", ".Net Framework (ver X.Y)", "Mono", etc...

This sort of glossary is definitely useful and very handy to have a visual "at a a glance" reminder.
Cheers!

Your explanation for the ".NET Standard" used the word "specification", which made a big difference. Just saying ".NET Standard" made me think of a runtime, right or wrong.

Thanks for this Scott, this is very much needed with all that is happening in .NET these days.

I tag along with the others in the "color contrast" train. There should definitely be a clearer visual separation between these boxes.

I have the same feeling as Tom about the nesting. Especially the blue section with languages, runtime and tooling. It feels a bit mixed up.

Also, .NET Standard, in my head, is something broader than what is visually represented. I don't know how the best way to put it would be, but the message should be "this is the set of APIS available to you for building this library". Right now it feels like it is somehow embedded in the library.

Again, thanks for this. Can't wait to see the final version!

Most makes sense to me , although I'm a little thrown by the apparent repetition between your 'CLR/CoreCLR' box and the 'An implementation of .Net is a runtime...' box. Is this not the same thing expressed twice?

If your intention was to list the implementations (which I think would be helpful) then I'd merge the two boxes at the 'lower' level and include Mono/Xamarin and other implementations there.

In general though a really useful diagram, great job and thanks for sharing.

Hmm not sure this works for me. The layering seems off and there seems to be a mishmash of physical and logical concepts in here. I would be tempted to lay this out explicitly from the view of a developer.

Put the languages/compilers that developers work in on top. Everything underneath (for the most part) is .Net not language specific and what things are written in is more of an implementation detail.

How are Application Frameworks differentiated from a MetaPackage or even a collection of Packages? Certainly, something like Asp.Net is delivered as a Metapackage. I wonder if you should treat the two almost as synonyms.

.Net standard in the middle kind of works. It does miss out that there are still separate frameworks and they all have extra API's unavailable to Standard or other frameworks. However, that might be hard to visualise so perhaps not worth considering here.

.Net SDK so seems to represent the development time installer, you don't need the SDK to deploy an application. I'd either drop this or make it a top-level concern with the languages/compilers and perhaps add in SKU's .Net FX, .Net Core etc...

I would either separate out each of the major runtimes (or at least CLR, Core CLR and Mono), then put those over the same big blue box as the "An implementation of blah". Or alternatively, leave as one and add the "An implementation..." text into the same box.

Then sit that over Platforms as you have already.

Hope this helps!

Scott: I hate the use of word 'platform' since it is vague. Adding to it, Platform example given in post, is confusing. I fail to understand why we are calling Operating System + hardware as a platform.

In "“Is that an ASP.NET Core app running in Docker on a Raspberry Pi?” example, Raspberry Pi is device and Raspberian is OS. So, not sure what is called here as a platform.

Hope this helps.

The term Platform is polysemous.

While most people like to think of platform as being OS + Hardware, Microsoft often refers to .NET Core, .NET Framework, etc. as platforms, for example, in this post.

I think they do this because framework can be confusing too. Generally, we think of frameworks as libraries, but .NET includes runtimes and compilers, which are more akin to as OS.

I actually just wrote a blog post discussing this very issue yesterday.

very confusing are the terms '.net core' and 'asp.net core'. The fact that 'asp.net core' can run on .net core or .net classic (if thats the correct name)

@pm100 ".net classic" is called .NET Framework.

Some of the layering confuses me.

Packages are made up of libraries makes sense.

But the inclusion of .NET Standard in Library/Assembly doesn't fit right for me. Does every library implement .NET Standard? I think of .NET Standard as of a collection of APIs, which is probably implemented with a collection of libraries. Am I misunderstanding?

And I'm really not sure how .NET SDK quite fits into that.

Perhaps I'm being confused by a mixture of "This is used to implement that" and "This makes calls into that"?

Very interesting. Just started studying computer science. I know a lot of Java and a little C# from using Unity game engine. But you've got me curious about how Java works too,msomce it's also a cross platform tyoe language. Would love to compare both.

I like the initial draft.

A few things that came to mind, is metapackage the right terminology? Maybe say composite package or package collection (ICollection<NugetPackage>)?

Related to that, how is this collection of packages different from an application framework? From the example, they seem to both be representing the asp.net core web framework.

Modules lost somwhere between assembly and .net standard

I think ".NET Standard" needs to clarified as an **API surface**, that is implemented by one or more assemblies provided by a given runtime. In the beginning it was really bad when it was called the ".NET Standard library", this gave a completely misleading designation, that this was some one for all set of mother assemblies for all. It is not. It is an agreed upon versioned API set, that any runtime compatible with needs to supply/provide.

Ha so try to squeeze that into one sentence. ".NET Standard is an **API surface** provided by a given runtime." maybe...

This is awesome !!

where's Powershell and a whole slug of other languages.

Hi Scott thanks for the knowledges, Im currently using Visual Basic.NET language, especially for windows form. Sorry for Out of topic, I want to ask if there is a away how to download special packages Visual Studio 2017 just for windows form and mobile development only? thank you.

I don't think you should nest all these subjects. This audience is confused already with all the glossary so it has to be clear whats a sub-item and what is just related. I therefore think that the previous .NET Standard images are a better representation. Those give a clear layered view of what is on top of what and what are actually grouped components.

I would like to see your image in this format:
https://msdnshared.blob.core.windows.net/media/2016/09/dotnet-tomorrow.png

Do not touch the explanation (example sentences); it is great!

I don't care the diagram, the explanation is the point!

Sorry for my english :)

Metapackage sounds to me as a package that contains description.
If it's a package of packages, what about Nested Package or perhaps Ordered Package?

I could not do the new Core 2.0 Identity stuff with standard2.0 ckasslib, why should I use it?

Hi Scott,

One thing I find confusing in diagrams like this is why something conceptually fundamental like a language (C#, F#, etc.) is shown on the same level as the SDK and the CLR. From my naive ASP.NET perspective I would have expected that the SDK would be a collection of optional assemblies and the CLR would be something underneath the languages. I'm not saying any of that is true, just giving my naive perspective of why I find that part of the diagram confusing.

Regards,
Iian

I think we could benefit from something like this.

However I think that the assembly box and it's contents could lead to confusion IMO. I think it should be clearer that a package can contain a number of assemblies, which may or may not target netstandard versions. Also those blue boxes (Languages, SDK, CLR) should move out too.

I think Artemigos nails it by saying there are 3 separate concerns. To bring them all together in a unified hierarchy I do not think will help newcomers.

It might be helpful to include where Portable Class Libraries (PCLs) fit in this diagram, as .NET users shifting from previous versions may wonder how .NET Standard is affecting those, and whether they can still work together in one solution.

It so helpful, thank you Scott.

آیکیا
ایکیا
مبلمان ایکیا
صندلی
جاکفشی
کمد ایکیا
آباژور ایکیا
جهیزیه عروس