有关C# 8.0、.NET Framework 4.8与NET Standard 2.1的一个说明
早在本月12日，微软官方的.NET Blog发布了一篇名为《Building C# 8.0》的文章，介绍了很多C# 8.0的新特性。不过本文主要讨论的并不是C# 8.0的新特性，而是存在于这篇文章中的一段文字：
我在2018年3月24日上海MVP线下技术交流活动中，分享过C#7.x的新特性，并且做了一场演示，展示了将C# 7.2 target到.NET Framework 2.0的工程，并在2.0的工程中使用C# 7.2的语法特性进行开发。由此看来，这是完全可行的，前提是，我所使用的开发库必须是可基于CLR 2.0运行的。你会发现，即使我使用C# 7.2，我仍然无法在一个2.0的工程中使用async/await的异步框架，原因是，async/await所依赖的TPL只能运行在4.0的CLR上，因此，C# 7.2可以target到.NET Framework 2.0，但是有一部分语言特性无法使用，这种情况同样发生在上面的C# 8.0上。
据此分析，.NET Standard 2.1引入新的API（比如Span<>）需要修改.NET的公共语言运行时（Common Language Runtime，CLR），这样的修改，对于.NET Core、Xamarin、Unity以及Mono这些重新设计的框架来说，应该更为方便；而对于经典.NET Framework这种具有历史特点的框架来说，或许并不那么直接容易，所以，.NET团队推后了经典.NET CLR的变更计划，由此也就推后了.NET Framework对于C# 8.0新特性的支持计划，因此，.NET Framework 4.8仍然只支持.NET Standard 2.0，部分C# 8.0的新特性无法使用。
经典.NET Framework的公共语言运行时（CLR）在整个.NET的发展进程中也就只出现过4个版本：1.0/1.1/2.0/4.0。 1.0和1.1基本上可以忽略不计了，估计现在已经没有什么项目在用这两个版本相对应的.NET Framework了。让大家最为熟知的是.NET CLR 2.0和4.0的版本：CLR 2.0随着Visual Studio 2005的发布，直到Visual Studio 2010的CLR 4.0，一共有5年时间；而2010年随着Visual Studio 2010一起发布的.NET CLR 4.0，至今也有近9年的历史了。随着.NET Standard API的不断扩展，相信不久的将来，我们会迎来一次CLR的版本升级，使得经典.NET Framework能够更好地支持.NET Standard API以及新的编程语言特性，契合整个.NET的平台架构。
Most of the C# 8.0 language features will run on any version of .NET. However, a few of them have platform dependencies. Async streams, indexers and ranges all rely on new framework types that will be part of .NET Standard 2.1. As Immo describes in his post Announcing .NET Standard 2.1, .NET Core 3.0 as well as Xamarin, Unity and Mono will all implement .NET Standard 2.1, but .NET Framework 4.8 will not. This means that the types required to use these features won’t be available when you target C# 8.0 to .NET Framework 4.8.这里的文字说的是，文中所介绍的绝大部分C# 8.0的新特性都可以在任何版本的.NET上使用，唯独有个别的功能需要在特定版本的.NET上才能使用。比如，Async streams，indexers and ranges这些特性都需要依赖于由.NET Standard 2.1引入的新类型，根据Immo在他的博客中所述，.NET Core 3.0、Xamarin、Unity以及Mono都会实现.NET Standard 2.1，而.NET Framework 4.8却不会。这也就意味着，这些C# 8.0的新特性，无法在目标框架为.NET Framework 4.8的情况下使用，也就是说，这些C# 8.0的新特性，无法在经典的.NET环境中使用。如此看来，貌似与以前展示的.NET平台架构有所出入，因为新版本的.NET Framework并不实现.NET Standard 2.1。
我在2018年3月24日上海MVP线下技术交流活动中，分享过C#7.x的新特性，并且做了一场演示，展示了将C# 7.2 target到.NET Framework 2.0的工程，并在2.0的工程中使用C# 7.2的语法特性进行开发。由此看来，这是完全可行的，前提是，我所使用的开发库必须是可基于CLR 2.0运行的。你会发现，即使我使用C# 7.2，我仍然无法在一个2.0的工程中使用async/await的异步框架，原因是，async/await所依赖的TPL只能运行在4.0的CLR上，因此，C# 7.2可以target到.NET Framework 2.0，但是有一部分语言特性无法使用，这种情况同样发生在上面的C# 8.0上。
据此分析，.NET Standard 2.1引入新的API（比如Span<>）需要修改.NET的公共语言运行时（Common Language Runtime，CLR），这样的修改，对于.NET Core、Xamarin、Unity以及Mono这些重新设计的框架来说，应该更为方便；而对于经典.NET Framework这种具有历史特点的框架来说，或许并不那么直接容易，所以，.NET团队推后了经典.NET CLR的变更计划，由此也就推后了.NET Framework对于C# 8.0新特性的支持计划，因此，.NET Framework 4.8仍然只支持.NET Standard 2.0，部分C# 8.0的新特性无法使用。
经典.NET Framework的公共语言运行时（CLR）在整个.NET的发展进程中也就只出现过4个版本：1.0/1.1/2.0/4.0。 1.0和1.1基本上可以忽略不计了，估计现在已经没有什么项目在用这两个版本相对应的.NET Framework了。让大家最为熟知的是.NET CLR 2.0和4.0的版本：CLR 2.0随着Visual Studio 2005的发布，直到Visual Studio 2010的CLR 4.0，一共有5年时间；而2010年随着Visual Studio 2010一起发布的.NET CLR 4.0，至今也有近9年的历史了。随着.NET Standard API的不断扩展，相信不久的将来，我们会迎来一次CLR的版本升级，使得经典.NET Framework能够更好地支持.NET Standard API以及新的编程语言特性，契合整个.NET的平台架构。
