It’s huge, has 2 decades of legacy, and has many parts. Here’s the main ones.
1. Virtual machine and JIT compiler, usually called CLR = Common Language Runtime, it runs byte code called CIL = Common Intermediate Language. They have renamed it a few times; older docs/tools may call the byte code MSIL = Microsoft Intermediate Language, or just IL. In modern .NET this thing is platform-agnostic.
2. Standard libraries for that runtime. The modern implementation is called CoreFX. It includes large count of batteries: collections, LINQ, threading and synchronization, async-await runtime, reflection, and much more. Fortunately, CIL is very compact representation of code, takes a small fraction of an AMD64 equivalent.
The lower-level pieces are platform-agnostic, but there’re many windows-only pieces implementing GUI and integration with other OS-specific services like WMI, registry, ADSI and more. For WinForms and similar they just use [DllImport] to consume Win32 and GDI+. For WPF this includes large amount of compiled C++ DLLs that consumes DirectX 9 to render GUI and implement resource-intensive algorithms. For UWP this includes COM interfaces to call native Windows APIs (albeit these interfaces might be a part of Windows SDK, I’m not sure).
3. Programming languages and compilers for them, the main ones supported by MS are C#, VB.NET, and to lesser extent F#. Modern version has a single compiler for C# and VB called “Roslyn”, F# is a separate program. There’re third-party ones, see IronPython. Also some .NET based products include their custom compilers or code generators who produce CIL code from something else in runtime, I did it a few times, not too hard.
There’re smaller pieces like framework SDK (a set of command-line tools to create, compile and run projects), msbuild (a build system typically used on Windows or for larger projects), and many other random programs/libraries of varying utility.
Update: Forgot an important component, NuGet package manager. It’s an equivalent of Python’s pip, or JavaScript’s npm, an online repository of code packages. The majority of packages there only contain CIL code, i.e. they’re very small and platform-agnostic. The most popular package there is an alternative Json parser, was downloaded 650M times. Microsoft uses nuget to deliver optional pieces of the standard library, developers like me are publishing their weird libraries too https://www.nuget.org/profiles/ConstMe
Yes. Also .NET native, remoting, WCF, asp.net, and lots of other things. Two reasons.
1. The ecosystem is huge. People are writing thick books on these subjects.
2. Most of the above (except asp.net) is windows-only stuff. Even on Windows, the stuff most useful if you’re maintaining something from 10-20 years old, less so for new projects, at least in my experience.
Well, C++/CLI support was the biggest feature for the .NET Core 3.0 release, so it does matter.
Although I do concede that most likely Microsoft would happily get rid of it, and have everyone make use of C++ code in .NET via UWP components instead, preferably using C++/WinRT.
1. Virtual machine and JIT compiler, usually called CLR = Common Language Runtime, it runs byte code called CIL = Common Intermediate Language. They have renamed it a few times; older docs/tools may call the byte code MSIL = Microsoft Intermediate Language, or just IL. In modern .NET this thing is platform-agnostic.
2. Standard libraries for that runtime. The modern implementation is called CoreFX. It includes large count of batteries: collections, LINQ, threading and synchronization, async-await runtime, reflection, and much more. Fortunately, CIL is very compact representation of code, takes a small fraction of an AMD64 equivalent.
The lower-level pieces are platform-agnostic, but there’re many windows-only pieces implementing GUI and integration with other OS-specific services like WMI, registry, ADSI and more. For WinForms and similar they just use [DllImport] to consume Win32 and GDI+. For WPF this includes large amount of compiled C++ DLLs that consumes DirectX 9 to render GUI and implement resource-intensive algorithms. For UWP this includes COM interfaces to call native Windows APIs (albeit these interfaces might be a part of Windows SDK, I’m not sure).
3. Programming languages and compilers for them, the main ones supported by MS are C#, VB.NET, and to lesser extent F#. Modern version has a single compiler for C# and VB called “Roslyn”, F# is a separate program. There’re third-party ones, see IronPython. Also some .NET based products include their custom compilers or code generators who produce CIL code from something else in runtime, I did it a few times, not too hard.
There’re smaller pieces like framework SDK (a set of command-line tools to create, compile and run projects), msbuild (a build system typically used on Windows or for larger projects), and many other random programs/libraries of varying utility.
Update: Forgot an important component, NuGet package manager. It’s an equivalent of Python’s pip, or JavaScript’s npm, an online repository of code packages. The majority of packages there only contain CIL code, i.e. they’re very small and platform-agnostic. The most popular package there is an alternative Json parser, was downloaded 650M times. Microsoft uses nuget to deliver optional pieces of the standard library, developers like me are publishing their weird libraries too https://www.nuget.org/profiles/ConstMe