The mysteries of the. NET Core cross-platform [prev]: The shackles of history

Microsoft introduced the first version of the. NET Framework as a framework for Windows desktops and servers, after which Microsoft cropped the. NET Framework based on the needs of the device itself, and introduced. NET for specific device types. Framework version to enable support for mobile, tablet, and embedded devices. In addition to this, a maverick monkey (Mono) is a consistent wandering outside the Windows platform. NET platform seems to be thriving, but in reality it is the only right way for Microsoft to go, and that is to redesign the. NET Core based on the cross-platform concept, as well as the whole. NET platform for a new layout.

The mysteries of the. NET Core cross-platform [prev]: The shackles of history
The mysteries of the. NET Core cross-platform [medium]: The War of Reuse
The mysteries of the. NET Core cross-platform [next]: New layouts

For computer practitioners, "Platform (Platform)" is a common term, in different contexts it has different semantics, such as it can refer to the operating system environment and CPU architecture type, can also represent the type of hardware devices. After years of painstaking, Microsoft has built a complete, multi-device-enabled. NET ecosystem for the Windows platform. At the same time, through the help of Mono and Xamarin,. NET can be successfully ported to non-Windows platforms including Mac OS X, Linux, IOS, Android, and FreeBSD.

I.. NET under Windows

Microsoft introduced the first version of the. NET framework in 2002, a framework that is primarily geared towards Windows desktop (Windows Forms) and server (ASP. Web forms). Since then, the dominance of the PC has been challenged and even replaced by other devices, and Microsoft has simplified and changed the. NET Framework based on the needs of the device itself, and has introduced the. NET Framework for specific device types, mainstream including windows Phones, Windows Store, Silverlight, and the. NET Micro framework provide support for mobile, tablet, and embedded devices, respectively. Because these different. NET Framework branches are completely independent, this makes it difficult to develop a "portable (portable)" application that supports multiple devices.

The. NET Framework Hierarchy

The independence of the. NET framework for different devices resulted in many cases where we had to program for specific device platforms, and reuse of code across device platforms was extremely difficult. In order for readers to have a deep understanding of this problem, we start with the structure of the. NET Framework. From a structural standpoint, the. NET Framework consists of two chromatography as shown, which are the CLR (Common Language Runtime) that provides the operating environment, and the FCL (Framework Class Library) that provides the API.

The CLR is to. NET equivalent to the JVM of Java, which is a. NET virtual machine. As a runtime (runtime), the CLR provides a managed (Managed) execution Environment for program execution, which is the execution engine of the. NET framework that provides services for the execution of managed programs in memory allocation, garbage collection, security control, exception handling, and multithreading management. The CLR is a subset of the. NET framework, but they have different version policies. So far, Microsoft has only released 4 versions of the CLR, respectively 1.0, 1.1, 2.0, and 4.0,.net Frameworks 1.0 and 1.1, respectively, using the CLR 1.0 and 1.1,CLR 2.0 by the. NET Framework 2.0 and 3.x are shared, and the runtime is CLR 4.0 under the. NET Framework 4.x.

The FCL is a class library designed to provide APIs to developers, and the APIs provided by it can be divided into two levels as shown. The bottom-most part is called the BCL (Basic Class Library), which provides a set of underlying types that describe some basic data types and structures (such as strings, numbers, dates/times, and collections) and provide some basic operations (such as IO, diagnostics, reflection, Text encoding, security control, multithreading management, etc.). Above the BCL are APIs for specific application types, and we can roughly classify them into the next three types:

• application-oriented (e.g. ASP. NET, WPF, Windows Forms, etc.)
• Service-oriented (e.g. WCF, WF, data services, etc.)
• Data-oriented (e.g., ADO, Entity Framework, LINQ to SQL, etc.)

We can also re-partition the FCL in another way: it will target an application or service type such as Windows Forms, WPF, ASP. NET and WCF, etc.), the entire. NET Framework has a three-tier structure as shown in Appmodel.

Chatty's BCL

We know Microsoft's. NET strategy was presented in the millennium, and two years later the first. NET Framework version and IDE (Vs.net 2002) came out. In the next more than 10 years, a series of versions of the. NET framework were launched. Microsoft is currently releasing the latest. NET Framework version of 4.7, showing you the evolution of the entire. NET Framework and the main features offered by each version.

2-3 outlines the development history of the. NET Framework over the years to illustrate the issue: as the infrastructure of the entire. NET platform, the. NET Framework is becoming more powerful and complete in its own way, but on the other hand it is becoming more and more bloated. As the version continues to escalate, the application model, the BCL, and the runtime (CLR) that make up the. NET Framework are constantly expanding (. NET Framework 2.0/3.x and. NET Framework 4.x, respectively, with CLR 2.0 and CLR 4.0), This is a very visual illustration of the problem.

We know that the assembly is. NET most basic deployment unit, regardless of how many of these types are used, the CLR always loads the entire assembly into memory. For the three tiers described above that make up the. NET framework, the application model is specific to the application/service type, The corresponding API is hosted by a separate assembly (such as the core framework of ASP. System.Web.dll in assembly, the assembly that hosts the entire Windows Forms framework is System.Windows.Forms.dll), so. NET Each application model of the framework is independent of each other. In developing some kind of application, we just need to refer to the corresponding assembly of the application model, that is to say we are developing a Windows Forms application that does not need to refer to the System.Web.dll assembly.

But most of the core code of the BCL is defined in the core assembly of Mscorelib.dll, so the BCL is basically an indivisible whole in the. NET Framework.. net The framework needs to provide support for the various types of managed programs running natively, and the underlying types for all application types need to be defined in the BCL. In many cases, our application may just need to use a small subset of the BCL, but we have to load the entire assembly into memory.

On the one hand, the BCL is always loaded as an indivisible whole, and its own size is constantly expanding as the. NET Framework upgrades. This should not be a big problem for client applications (such as Windows FORMS/WPF Apps), but the resulting response to performance and throughput is an issue that has to be considered for mobile and server-side applications, including those deployed in cloud applications.

The ideal BCL consumption is "on demand" and we need that part to load that part. Because an assembly that is a standalone deployment unit is always loaded into memory as a whole by the CLR, the only way to fully implement this ideal BCL consumption is to divide it into small units and define them separately into separate assemblies. In addition, it is easier to split the entire BCL according to the modular principle, if the existing version has bugs that need to be fixed, or if the performance needs to be improved, then just change and upgrade the appropriate modules. Shows the. NET framework hierarchy with a modular BCL.

Multiple device platforms alone for political

After years of operation, Microsoft has built a complete support for our various devices. NET ecosystem, from the original simple desktop platform, gradually expanded to mobile, tablet and embedded platforms. The differences in the operating environment of the devices have led to applications that are not built on a unified. NET Framework platform, so Microsoft uses a separate. NET Framework platform to provide targeted support. For now, in addition to the full version of the. NET Framework, which supports Windows desktop and server devices, Microsoft has launched a series of "compressed. NET Framework", which includes Windows Phone, Windows Store, Silverlight and the. NET Micro framework provide support for mobile, tablet, and embedded devices, respectively.

These. NET frameworks do not provide a development framework for the corresponding device platforms only at the Appmodel level, and they provide different BCL and runtime. In other words, these. NET Framework platforms are completely independent, and the independence between different. NET Framework platforms is intuitively reflected. The independence of the target platform makes it difficult to write code that can be reused across platforms, and we'll focus on this in the next section, "Reusing wounds."

Ii.. NET under non-Windows

While Microsoft itself has largely worked on only one acre of land on the Windows platform for many years,. NET extends tentacles to other platforms (Mac OS X, Linux, iOS, Android, etc.) through mono and Xamarin. Although not perfect at the moment, we can say. NET has the ability to cross-platform.

Speaking from the CLI

. NET cross-platform capability is based on an open standard or specification, the so-called standard/specification is the CLI. The development of the CLI is designed to address the problem that. NET applications developed by different (advanced) programming languages can run in different system environments without any changes. To achieve this goal, it is necessary to effectively address the two types of differences that are involved in programming language differences and runtime environments. Programming languages can be mutually compatible, the runtime environment can be unified, cross-platform Albert can achieve.

The CLI is all called Common Language Infrastructure, where common Language is language, specifically a common language designed to address the compatibility issues of various advanced development languages. Infrastructure refers to the runtime environment, which is designed to bridge the differences in how different platforms are executed. Common language is a static description of the binary content that hosts the app, and infrastructure represents the engine that executes the application dynamically, so the CLI establishes a uniform standard for executable code and execution engines.

Programming languages have compiled and interpreted types that need to be compiled by compilers to generate executable code, and the common language referred to by the CLI refers to a compiled language. To achieve a true cross-platform, the ultimate solution is the compatibility and portability of executable code between different platforms, and the choice of programming language only determines the original state of the application's source files, and the compatibility of the application is determined by the compiled results. The difference between programming languages is no longer a problem if applications developed through different programming languages can generate standard target code by compiling the corresponding compiler.

According to the CLI, a language used to describe executable code is called CIL (Common Intermediate Language), which is an intermediate language between high-level and machine-language. As shown, although the program source files are written in different programming languages, we can compile them into CIL code with the appropriate compiler. In principle, we can design a new programming language and add it to it. NET family, you simply need to generate unified CIL code with the appropriate compiler. We can also design a CIL-targeted compiler to be a. NET language for an existing programming language. CIL is an intermediate language and an object-oriented language, so for a CIL program, the type is the basic constituent unit and the core element. Microsoft has developed a specification known as the CTS (Common type System) that establishes a unified type for the CLI.

Differences in programming languages are "vm:virtual" by the compiler, and differences in the operating environment can be solved by virtual machine (VM) technology. A virtual machine is a CIL execution container that can be dynamically translated into a machine instruction that exactly matches the current execution environment in a timely manner during the execution of the CIL code. The virtual machine masks the differences between different operating systems so that the target program can run in a different underlying execution environment without any modification, and CIL is actually a virtual machine language.

From the principle of implementation, it is not difficult to make. NET cross-platform, but to involve a variety of relevant people to build a healthy and perfect cross-platform. NET ecosystem is not destined to happen overnight, the stakeholders involved include the designers of programming languages, and the people who design and develop compilers, virtual machines, Ides, and other related tools, including, of course, the vast majority of application developers. Cross-platform. NET ecosystem must be built on a standard specification, so Microsoft developed the CLI and then submitted it to the European Computer Manufacturers Association (Ecma:european Computer Manufacturers Association) and was accepted by the latter, Became a specification numbered 335, so the CLI is also known as ECMA-335 (by the way, ECMA has accepted Microsoft's specification for the programming language of C #, i.e., ECMA-334).

Mono and Xamarin

The open specification of the CLI (ECMA-335) has given it a cross-platform gene at the moment of the birth of. NET, but Microsoft, branded with Windows, does not seem to have ever thought of extending. NET to other platforms, truly fulfilling this mission is a project called Mono. Although Mono is a very young project, there are still a lot of people who don't know about it, so let's take a brief look at its history.

In 1999, Miguel de Icaza created a company called Ximian, a GNU project designed for the GNOME project, a desktop environment for UNIX-like systems, Gnome is currently one of the most commonly used desktop environments in Linux) to develop software and provide support for the company. In June 2000, Microsoft formally released the. NET Framework,miguel de Icaza by a "new Internet-based development platform" (. NET was advertised as "a new platform based on Internet standards" when it was released. ) deeply attracted. In November, Microsoft released the CLI specification (ECMA-335) and developed an independent implementation license for the public, Miguel de Icaza saw the opportunity, as it actually was. NET to the non-Windows platform provides the possibility. Miguel de Icaza opened the Mono project in July 2001 and uses C # as the main development language (currently supported by VB. NET), so the two ECMA specifications for the CLI and C # are the rationale for building a mono project, and if you visit the official website of Mono, we will find that it defines mono as: "Mono is an open source implementation of Microsoft's. NET Framework based on the ECMA standards for C # and the Common Language Runtime. "

Mono's mission is not limited to the ability to run. NET applications on other non-Windows platforms, it also wants to help developers develop. NET applications directly on other platforms, so Mono has developed the CLR and compilers as virtual machines for the corresponding platform, not just based on the CLI. It is also provided to the IDE and the appropriate development tools (known as MonoDevelop). The first official version of Mono (Mono 1.0) was released almost three years after the project was opened (June 2004).

In August 2003, Ximian was acquired by another company called Novell, which continued to support the development of the Mono project by Miguel de Icaza, during which a number of mono 2.x versions were introduced. In April 2011, Novell was also acquired by another company called Attachmate, who decided to abandon mono, so Miguel de Icaza with the entire mono team set up a new company named Xamarin. In July, Xamarin received a development license for mono from the original parent company, Novell. In the following years, Xamarin has released Mono 3.x, Mono 4.0, and Mono 5.x, the latest version of which is 5.4. Mono's goal today is to implement. NET 4.5 all features except WPF, WF, and partial WCF, and the current missing part is being developed through a project called Olive (a subproject of mono).

On the basis of the Mono project, Xamarin began developing products named after the new company, the most important of which is Xamarin 2.0, released in February 2013. Xamarin 2.0 consists of xamarin.android, Xamarin.ios, and xamarin.windows, which enable us to develop native apps for Android, iOS, and Windows in C #. In addition, Xamarin 2.0 also carries an IDE called Xamarin Studio (MonoDevelop) and some tools integrated with Visual Studio. The May 2014 Xamarin 3.0 release, as its core xamarin.forms, provides unified controls for native applications of different platforms, which means we use xamarin.forms API Development native apps can run on Android, iOS, and Windows without any changes.

In February 2016, Microsoft and Xamarin announced that the two sides signed an agreement to reach the former takeover of the latter. At the 2016 build conference, Microsoft announced the open source of the entire Xamarin SDK and integrated it as a free tool into Visual Studio, and users of Visual Studio enterprise are free to use all the features of Xamarin Enterprise Edition.

In summary, due to. NET is built on the standard of the CLI, so it is inherently a "cross-platform" gene. After Microsoft released its first. NET Framework for desktop and server platforms, it began "happily" doing different scopes and levels of "castration" for the full version of the. NET Framework, which in turn created Windows Phone, Windows Compact version of the. NET Framework for the Store, Silverlight, and. NET Micro framework. In this sense, mono is not fundamentally different from them, except that mono really breaks through the barriers of the Windows platform. These branches, including mono, have contributed to the prosperity of. NET, but we all know it's just a false boom. Although they are all subsets of the. NET framework, because they employ a completely separate runtime and base class library, it makes it difficult to develop a "portable (portable)" application that supports multiple devices, but these branches become constrained. NET development of a road yoke. As for why "portable (portable)". NET app is so cumbersome, stay tuned for medium ". NET core cross-platform mystery [medium]: The War of Reuse."

The mysteries of the. NET Core cross-platform [prev]: The shackles of history