What is and how does . NET Platform Standard work?

Question

Recently I have studied the . NET Core and ASP.NET Core and one of the changes to the RC2 version that is to come, as far as I know, is called . NET Platform Standard. This standard is described in official document on Github.

Reading the official document I did not understand very well, perhaps because I have never studied about PCL (Portable Class Libraries). From what I understand the idea is to describe a way to identify platforms for which code is compiled.

I personally found the document a little confusing. I don’t even really understand this idea of platforms and what problem is being solved by this pattern.

So: what is . NET Platform Standard really about? What problem does it actually solve and how does it solve? What are these various platforms and why we need to worry about them?

Answer 1

Platforms . NET

When . NET Framework was created the idea was to have a framework for developing desktop applications on Windows. We can say that the framework itself was composed of three main components:

• The CLR (Commom Language Runtime) - In short it is a "Execution Engine" containing everything needed to run the applications. NET compiled in IL. When the application . NET is compiled the compiler does not directly generate a native executable in machine language, but rather files in an intermediate language called MSIL (Microsoft Intermediate Language). The CLR includes the JIT compiler, garbage collection mechanism, etc. It receives the MSIL files, uses the JIT to transform into native code, and allows the execution of the application.

• The BCL (Base Class Library) - It is the basic class library included with the Framework. When the . NET Framework is installed on the machine the entire BCL is copied to the GAC (Global Assembly Cache). The applications . NET when dependent on a basic Assembly search in GAC and so have access to version of BCL installed with the Framework.

• Support software - What I call support software here includes the software responsible for initializing the CLR, providing the interface with the Operating System, etc.

Although it works well on the Desktop, over time the need to use . NET in new environments has arisen. This gave rise to "new forms of . NET". Some examples are Silverlight, the Windows Phone 8 apps and the Windows Store apps.

In those cases all the full . NET was inconvenient. O . NET is very heavy and therefore very expensive to run in a browser or on a mobile phone. Moreover, to run, for example on mobile phones, an optimized framework was necessary to avoid, for example, an absurd battery expenditure.

Each of these new environments has made it possible, from the original . NET, to create a "specialized framework". Each specialized framework had its own Runtime, its own basic class library and its own support software.

The basic library of each of these platforms included what was considered necessary for the platform. And often something only makes sense on one platform: for example, the Windows Forms Apis don’t make sense on Silverlight or Windows Phone in the same way that the Apis for interacting with a mobile phone don’t make sense on the Desktop.

In short, a platform consists of a Runtime, a basic library and the support software. The code we build runs on top of a specific platform by the Runtime of it.

The Multi-platform Compile Problem

Despite the strategy of having several "types of . NET", each one suitable for an environment, have solved the problem of optimizing the framework for each situation, this introduces a problem: encode a library of classes that works on more than one platform.

If we choose to develop only on a specific platform (for example .NET for Windows Desktop), we do not suffer from this problem. But if we want to develop for more than one platform, we may need to share code. If we develop software that will have a Windows Desktop version, a Silverlight version and a Windows Store version, we may end up needing to develop class libraries that need to be used on more than one platform.

The problem with this is that since each platform has its own basic library, we cannot guarantee that the Apis we use in our class library will work on all platforms.

PCL (Portable Class Libraries) solved this problem by identifying platform sets. This means that we developed class libraries for a fixed set of platforms and knew that we would only have access to the API’s available simultaneously on all platforms in the set.

Despite this approach solving the problem in one way, it introduces another problem: as the platform set was "hard-coded", if a new platform is created that supports the API’s used, the library cannot be used in it.

How . NET Platform Standard solves the problem?

The . NET Platform Standard is the proposed new solution to this problem. The idea is to have a single TFM (Target Framework Moniker) that identifies a pattern. This TFM has a version that identifies a set of available API’s. It’s something like the Android Level API.

The idea behind this is: every version of . NET Platform Standard establishes a contract. These contracts say which Apis should be available.

Each platform then "signs the contract" for a version of . NET Platform Standard. This means that the basic library of this platform presents with certainty at the very least the Apis of that contract, that version of . NET Platform Standard.

The developers of class libraries then develop not for a specific platform, or set of platforms, but for a specific version of . NET Platform Standard. It’s like using a code interface: we know the methods will be available. In this case, when developing for a specific version of . NET Platform Standard we are sure that the API’s of that version are available.

The advantage over PCL is exactly that if a new platform appears and supports those API’s, it just has to sign the contract for that version of . NET Platform Standard and the library code built for that version will work on the new platform.

In practice the . NET Platform Standard TFM is netstandardX where X is the version of . NET Platform Standard.

Now at the beginning there was a "backward versioning" of the API’s of the major platforms that exist today. This means that Microsoft has already defined versions 1.0 through 1.4 simultaneously. NET Platform Standard thinking about the Apis that today’s platforms offer.

The API’s of version 1.0 were chosen based on the platforms that provide the least API’s today, while version 1.4 is the version with all API’s.

The official document shows how this backward version works, with a table that allows mapping the versions of . NET Platform Standard for concrete platforms. Just look at the table to see, for example, that when developing for the . NET Platform Standard 1.3 the library will work, for example, on . NET Framework 4.6 and Universal Windows Platform 10.

As new platforms need new API’s the versions of . NET Platform will eventually evolve. Each new version includes all the API’s from previous versions and the new API’s that were chosen for the version.

In short, by developing for a version of . NET Platform Standard and not for a specific platform we have the guaranteed availability of the API’s of that version on the platforms that support it. This allows the class libraries we create to work on all current platforms that support that version of . NET Platform Standard as well as work on all new platforms that support this version.