Draft - .NET Glossary Diagram
I'm working on this slide as support for this excellent .NET Glossary. It's not done yet, but I'm curious for your thoughts. Every system has terms and concepts that are initially unfamiliar but make sense once you grok them.
Here are these concepts used in an example sentence, for context:
- Application Framework - “Are you using the ASP.NET Core web framework for that microservice?”
- Metapackage - “I want to install the ASP.NET Core framework; it’s a package of packages”
- Package/NuGet - “I know there’s a NuGet package for decoding JSON.”
- Library/Assembly - “Now, you’ll compile your source into an assembly”
- .NET Standard – “Which version of the .NET Standard specification does your assembly target?"
- "My Apple Watch supports .NET Standard 1.6 but my Windows 10 laptop supports 2.0 with more APIs.”
- C#, F#, VB, etc – “Which language did you use?”
- .NET SDK - “Did you get the developer tools?”
- 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
- “Are you using .NET Core, .NET Framework, or Mono for this project?”
- Platform - An operating system and some hardware (ARM, x64, etc.)
- “Is that an ASP.NET Core app running in Docker on a Raspberry Pi?”
Constructive feedback, please. This is a draft.
Sponsor: Check out JetBrains Rider: a new cross-platform .NET IDE. Edit, refactor, test and debug ASP.NET, .NET Framework, .NET Core, Xamarin or Unity applications. Learn more and download a 30-day trial!
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
You know, just to be sure everything is crystal clear.
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.
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.
CodeMonkey: See this slide, Boss- it explains what .NET Standard means.
Boss: Oh, ok great! Where do our Silverlight applications fit in?
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).
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?
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.
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/
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.
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.
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!
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.
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!
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.
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.
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"?
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.
Ha so try to squeeze that into one sentence. ".NET Standard is an **API surface** provided by a given runtime." maybe...
I would like to see your image in this format:
I don't care the diagram, the explanation is the point!
Sorry for my english :)
If it's a package of packages, what about Nested Package or perhaps Ordered Package?
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.
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.
Comments are closed.