When .NET Standard 2.0 and XAML Standard were announced at Build 2017 earlier this year, the industry was immediately abuzz with discussions about its impact on cross-platform development and the future of the technology.
Such talk is nothing new – since its original release in 2002, the .NET ecosystem has grown exponentially, with its many alternatives like .NET runtimes: .NET Core, Universal Windows Platform (UWP), Xamarin and Unity Game Engine, all having a sizeable impact on developers across the world. Yet, despite the shared similarities, like run time, there are some significant differences between their base class libraries (BCL), which leads to difficulty sharing source code. DotNetCurry delves deep into the soon-to-be release tech and offers up some insights.
Microsoft has long been working on a solution for its sharing source code problem. Its first attempt involved using portable class libraries (PCL); this allowed users to build binary compatible assemblies which could then be utilised with multiple runtimes. However, PLC necessitated the target run times to be selected when first creating the library because the calculation for the intersection of available APIs is contingent on this detail.
Yet, as the number of runtimes and various additional versions rose, this approach became ever more problematic and troublesome to manage. As a result, .NET Standard was implemented as an alternative for easier cross-platform development.
.NET Standard works by reversing the first method’s determination of available sets of APIs. Instead of calculating it using targeted runtimes, the update specifies them on its own and uses the runtimes to support them.
.NET Standard 2.0
Given that the main hindrance for .NET Standard 1.x adoption was its select number of available APIs, the update’s intention is to alleviate the issue by introducing 20,000 additional APIs. These APIs are already a part of .NET framework, but have been missing from .NET Standard before.
Experts predict that the increased number of APIs mean that it is much simpler to compile existing source codes that were initially written for .NET framework, against .NET Standard. It is thought that this will better enable the tech to run other runtimes (so long as it is not reliant on particular application models).
Alongside .NET Standard, developers also announced XAML Standard at Build 2017. It comes as an attempt to define standard XAML vocabulary elements for describing user interfaces. The first version (XAML Standard 1.0) is poised to be released later this year.
For DotNetCurry writer Suprotim Agarwal, the release of 2.0, .NET Standard and XAML Standard, marks the moment the tech shifts from “a promise tool for cross-platform development into an essential part of making .NET Core a more viable and attractive runtime.”
The increased number of available APIs means that creating cross-platform libraries for sharing common business logic between multiple runtimes (e.g. an ASP.NET Core web application, a desktop .NET framework application and a mobile Xamarin application will all share the same assemblies with business logic) much simpler.
While the tech is not ready for production or release, developers can use 2.0, .NET Standard for testing in their projects.