Modernizing .Net is a slow process. Although it’s not been hard for Microsoft to deliver a new, faster cross-platform runtime in the open source .Net Core, it’s been harder to bring code and developers to the new platform.
The biggest issue is compatibility. With the .Net Framework now nearly two decades old, there’s a legacy of APIs and functions that need to be supported in any new version, if code is to carry on running. Slight differences between API implementations can cause catastrophic bugs, or worse yet, can change outputs from version to version. So although .Net Core is smaller and faster than the full .Net Framework, code written for one won’t run on the other because there’s no common SDK.
Compatibility in .Net Framework is a bigger problem than it is in .Net Core, because .Net is in many different places. It’s the heart of Windows 10’s Universal Windows Platform (UWP), the foundation of the cross-device Xamarin and the related Mono project, as well as powering Unity’s 3D virtual reality, augmented reality, and gaming environment. Code written for one .Net isn’t guaranteed to run on another release—not without a little help from common libraries, that is.
.Net Standard levels the playing field
That’s where .Net Standard comes in. It’s a common set of libraries and APIs that provide a uniform programming surface. Code targeting the core features of .Net Standard will run on any platform that has it installed, though you may need to write UI-specific code for each and every target platform. That’s not surprising: Code written for ASP.Net Core will have different user interface requirements from code written for Xamarin running on Android or Unity on HoloLens.
A year ago, Microsoft shipped .Net Core 2.0 and .Net Standard 2.0. This was a major upgrade to the .Net common libraries, and it was the first release to really make writing cross-platform code possible. Although it didn’t have all the APIs of the .Net Framework, it went a long way to delivering on a familiar development experience, and although there were still issues with porting legacy .Net code to the new tools and libraries, the process was a lot easier.
