CLI 标准
.NET 框架起源于 Common Language Infrastructure (CLI)。CLI 由微软发起并成为 ISO 和 ECMA 的一个标准，它描述了一种开发方案，这种方案下可以用多种高级语言做开发软件，并可以运行在不同平台上。
CLI 的核心是运行时 Common Language Runtime (CLR) 。这里的 CLR 就像 Java 的虚拟机，但支持多种开发语言。.NET 程序员用 C#、F#、VB 等高级语言所写的程序，会被编译器 （如 .NET 的 Roslyn）转换为中间语言 intermediate language (IL) 存起来，等到实际运行的时候 CLR 再把 IL 转化成机器可以认识的指令 (JIT)。
这里插一句：现在 .NET 也有了 .NET Native，采用提前编译 (AOT) 而非即时编译，下文会提到。
这样做理论上就可以实现 CLI 的目标：多种高级语言都编译成一样的 IL 放着就行了，而只要用户的电脑上装了 CLI 的环境，就可以认识 IL 让程序跑起来。实际上我们在 Windows 电脑上常见到的各种 .dll 文件，就是存放的 IL。
.NET 构成
前边说了，CLI 只是一个标准。谁都可以在这个标准下做一套自己的方案。.NET 是微软自家对 CLI 标准的一个实现。不过微软过去并没有把这种可移植性真的发挥到 Windows 之外的系统中去。在人们印象中，.NET 框架一直都是 Windows 桌面软件开发的专属。虽然也有 Mono 这样的第三方试图实现一个真正跨平台的 CLI —— 就是另外写一套 CLR，能跑在 Windows 外的机器上 —— 但与微软的 「正统」.NET 从完善程度到影响力都不能同日而语。
每种 .NET 实现，包含以下几块：
- 运行时 Runtime
- 丰富的类库 Class Library
- 应用开发框架 Application Frameworks
- 其他开发工具
一般提到 .NET 框架，即所谓的「完整 .NET 框架」包含：
- 运行时 CLR
- 基本类库 .NET Framework Base Class Library (BCL)
- 应用开发框架有针对 Windows 桌面客户端 Windows Forms 和 Windows Presentation Foundation (WPF)，以及针对 web 的 ASP.NET 等
这就是过去几年 .NET 的一个总结：完整的 .NET 框架很强大但很封闭。
新的 .NET 实现
然而不能真正跨平台的 .NET 违背了 CLI 多语言、跨平台的初衷。尤其是移动端和倚仗 Linux 比较多的 web 端蓬勃发展，.NET 随着 Windows 平台略显萎靡。意识到这一点的微软开始自我革命，重写 .NET。更准确地说，是再实现另一套与传统的完整 .NET 框架不同的 .NET。
然后就有了 2016 年正式推出的焕然一新的 .NET Core。
开源的、跨平台的 .NET Core 包含了全新的运行时 CoreCLR 和从 BCL 中提取的核心类库 CoreFX，应用框架则有针对 web 端的 ASP.NET Core。而其他的平台上的开发， 可以采用原生或第三方的 UI 框架来搭配通用的 .NET Core 的代码。
注意，UWP 并非基于 .NET Core 的应用框架，虽然下图看上去会给人这种错觉。
UWP 可以通过提前编译，运行在任何 Windows 设备上，甚至不需要安装 .NET 环境。对下面这张图可以这样理解：既然前边提到的 Win Forms 和 WPF 都必须依赖完整的 .NET 框架，那对 .NET Core 开发者来说， Windows 客户端开发自然就要选择独立的 UWP 了。（实际上，这篇 .NET 术语表 把 UWP 也看作一种 .NET 的实现，这个我就不是特别明白了）
最后要说的是，微软正在推进 .NET Standard 标准。这个标准规定了所有 .NET 框架都要实现的一套接口。也就是说目前微软的想法是，完整 .NET 框架 与 .NET Core 等其他 .NET 实现并存，同时用 .NET Standard 来规范统一他们，并共用包括编译器在内的 .NET 基础设施。
[更新于 20/08/2017]