In designing portable languages, compiling to bytecode rather than architecture-dependent machine code can be a good way to produce multi-platform binaries which can be compiled at runtime using a JIT. C# and Java both leverage this, yet historically Java's portable nature has been leveraged to a much greater extent.
In order to accomodate the use of architecture-independent binaries, Microsoft produced the Common Language Infrastructure early on. This is not technically bound to C# or .NET; it purportedly provides a generic framework for creating a runtime. Components of the CLI include:
- The Common Type System (CTS), specifying type definitions, representations, and interoperability.
- The Common Language Specification (CLS), a subset of the CTS specifying the common set of language features that must be supported in order to be compatible with other CLS-compliant components. For the programmer, this can mean restricting their framework interface to only using CLS compliant types.
- The Standard Libraries, specifying a set of libraries that are to be provided for CLI programs. These libraries include functionality such as file IO, document parsing, networking, threading, and reflection.
- The **Virtual Execution System (VES), specifying the runtime that will CLI-compatible programs, executing the platform-independent instruction set.
For another perspective, please see Microsoft's own documentation on the anatomy of the CLI.
CLI languages compile to the Common Intermediate Language (CIL). CIL is comparable to LLVM Intermediate Representation, or to Java bytecode. Managed code is a similar term which refers to the higher level idea of "code whose execution is managed by a runtime", contrasted with unmanaged code that is more directly loaded into memory and executed.
CIL binaries are stored in assemblies, either as a process assembly (.exe) or library assembly (.dll). Within an assembly, the manifest describes general information such as the dependencies, versioning, and permissions required. The metadata specifies details about high-level code structure, including types and attributes.
Microsoft's .NET platform is the main implementation of the CLI. Though the CLI's discipline is followed, it falls short as a generic standard in that it's practically inseparable from the .NET family. Regardless, it's imperative to recognize .NET's role as a platform. If we were to conjecture a comparison to Java, the Java virtual machine specification is very roughly equivalent to the CLI, with .NET providing specific implementations. In addition to the JVM specification, the Java software platform also gives the Java Language Specification, for which there is no equivalent here. Unlike the Java platform, the .NET platform is decidedly language agnostic.
The line between the CLI and .NET becomes blurred when we draw these comparisons, and one will notice that some sites even consider the CLI and it's components to be a part of .NET. Pedantically speaking, this isn't correct, seeing as .NET implements the CLI rather than specifying it. Fortunately, in practice this distinction isn't important. The most important takeaway here is to understand the components of CLI, and how they manifest in the .NET stack.
.NET Framework (also see the official documentation was the first .NET platform, and historically has been the predominant implementation of the CLI. It was introduced in 2000, and has remained exclusive to Windows.
Prominent components of .NET Framework include:
- The Common Language Runtime (CLR), implementing the VES. Despite the "common" prefix in the name, this is indeed an implementation detail rather than part of the CLI specification. Aptly, though, the CLR can execute any language which is compiled to the CIL.
- The Framework Class Library (FCL), implementing the Standard Libraries. The FCL is seldom referred to as-is, with documentation often preferring to call it the class library or the .NET Framework Class library. It guarantees the Base Class Library (BCL) subset of the Standard Libraries, but its additions beyond this are crucial:
- Extensions to the BCL.
- Windows Forms (WinForms), a ubiquitous GUI library.
- Windows Presentation Foundation (WPF) (Microsoft Introduction, the less-ubiquitous successor to WinForms.
- Extensible Application Markup Language (XAML), introduced for WPF but made compatible with WinForms.
- ASP.NET, a web framework.
With more applications targetting .NET Framework and using these APIs outside of the CLI standard, to have an implementation of strictly just the CLI wouldn't be of much use. Despite pressure imposed by Microsoft patents imposed on its unstandardized components, some parties endeavored to create alternate implementations, often as free and open source software.
Mono preservered as the de facto free and open source .NET Framework reimplementation, supporting all major desktop platforms. It provides a compliant CLR virtual machine and nearly all of the FCL. Mono's FCL lacks support for WPF, but its WinForms implementation is still indispensible in using much of the vast library of .NET Framework applications on Unix-like systems. It also includes Mono-specific APIs, especially those for better integration with Linux and macOS.
Mono was started under the Linux/Unix based company Ximian, which had been bought by Novell prior to Mono's initial release in 2004. Later, as Mono was maturing, and .NET Framework 4.0 had been released, Novell layed off its Mono employees, leading to the creation of the Xamarin company, focused on creating Mono products. With Mono itself remaining free, Xamarin developed proprietary extensions to it, including ports to iOS (named Xamarin.iOS, formerly MonoTouch) and Android (named Xamarin.Android, formerly Mono for Android).
The BCL subset is considered the core set, and the full FCL the complete set
birth of .NET: https://tirania.org/blog/archive/2014/Nov-12.html
everything has subsets and supersets - a standard is needed!