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.
Over the last year, .Net Core has had its own significant updates, with Version 2.2 currently under development. There are enough low-level updates to .Net Core that it makes sense for Microsoft to bring out the new Version 2.1 of .Net Standard to support those new features and work with the latest version of the .Net compiler. When .Net Standard 2.1 is released, it’ll give you about 3,000 new APIs, along with support for some of .Net Core’s biggest performance upgrades.
That’s doesn’t mean you’ll need to upgrade your code to the new library as soon as it’s released. It’s important to note that the version of .Net Standard you use is the compatibility layer for all the versions of .Net you’re targeting. It’s much better to target the lowest version of .Net Standard possible, because you’ll have more compatibility options. You can, of course, target multiple versions of the .Net Standard libraries, but that adds complexity—contrary to the whole purpose of .Net Standard, which is to simplify your code base by reducing the number of API versions you need to work with.
Span<T> improves .Net performance
One of the more important changes in .Net Core 2.1 was the introduction of the Span<T> type. It gives .Net a new way of working with memory, one that lets it manage buffers more effectively, improving performance by reducing memory copying. Microsoft describes it as a “fundamental type,” because it can’t be used with older runtimes or compilers. That’s meant .Net Core 2.1 has a new set of APIs for working with spans, APIs that .Net Standard needs to use to extend its existing APIs.
Span<T> is an important new construct, especially if you’re writing high performance code. Where you might have had to make multiple allocations of standard types—for example, for the elements of a string you’re processing—you can now work with the memory that stores the original string, and you can handle it without having to allocate more memory.
It’s a quick and easy way of working, especially with how Span<T> and its Slice operator have been implemented as overloads to many common .Net functions. Similarly, you can use it to work directly with asynchronous network operations, quickly reading streams of data.
Where Span<T> comes to the fore is in working with microservices, especially if you need to process complex API calls and have to work with JSON data. Working with data in low-level network buffers, especially using APIs that can process UTF8 data directly, removes a significant amount of overhead and should give your code quite a performance boost.
Much of what’s new in .Net Core 2.1 can already be accessed through separate NuGet packages, but that approach can make code much more complex, requiring you to manage dependencies across all your apps. Bringing those new features into .Net Standard 2.1 will give you one place to access core APIs.
A new .Net governance model
Perhaps the most interesting aspect of .Net Standard 2.1 is that it’s bringing new APIs into .Net, rather than working to implement existing concepts. That’s an important change, because it also means that Microsoft will need to change how it runs the open source .Net program. As new features like Span<T> are introduced, they need to be made available through new .Net Standard APIs. Going forward, new releases of .Net Standard will be themed, focusing on particular API areas. With .Net Standard 2.1, it’s clear that the theme is speeding up memory management.
To reduce the impact on the entire .Net ecosystem, there’s now a review process that handles new API additions. With representatives from the main .Net implementations, and with Miguel de Icaza chairing the board, it’s clear that the community want to make sure that the fast-track development of .Net Core doesn’t break other implementations. That may mean having to stick with NuGet for some features, but improvements to the .Net tools in recent builds of Visual Studio should make that easier to handle.
.Net Standard 2.1 looks to continue Microsoft’s current juggling act, as it tries to balance moving forward the state of the art in .Net Core while balancing the needs of the rest of the ecosystem. Adding a significant number of new APIs will help here, and the new governance model for the project should make it easier for other .Net implementations to pick up new code more quickly and to build newer, more performant code. To understand why that’s good for developers, you only have to imagine the responsiveness of a HoloLens mixed-reality application in Unity that can handle 3D transforms at a buffer level.