C # Sharp Experience (III)

The third part is about Microsoft.NET Platform Foundation construction

It is meaningless to talk about C # without the Microsoft.NET platform, and the "Sharp" of C # is also a powerful platform behind it. Just adhere to the grammatical level is not experienced C # sharp Place, C # program Many secretive place must rely on Microsoft.NET platform to the depth of mastery and application. Simply put, the Microsoft.NET platform is a revolutionary new XML Web Intelligent Computing Service platform built on open Internet protocols and standards, using new tools and services to meet people's computing and communication needs. It allows applications to communicate with each other easily and quickly on the internet without having to worry about which operating system and programming language to use.

Technically, the Microsoft.NET platform consists of two cores, the common language runtime (Common Language Runtime, the CLR), and the Microsoft.NET Framework class library, They provide the underlying technical support for the implementation of the Microsoft.NET platform. The common language runtime is a service that is built at the bottom of the operating system and is the execution engine for the Microsoft.NET platform. The Microsoft.NET framework includes a set of class libraries that can be used in any programming language to make it easier for programmers to build web-based applications and services. On top of this are many application templates that provide advanced components and services for developing network applications and services. The vastness of the Microsoft.NET platform is not the thousands of words that can be clarified here, and we will focus on the platform infrastructure that is critical to our development of applications in C #.

Common language Runtime (CLR)

The common language runtime is the foundation upon which the entire Microsoft.NET framework is built, and it provides a managed code execution environment for Microsoft.NET applications. It is actually a piece of proxy code that resides in memory and is responsible for code management throughout the execution of the application, typically: memory management, thread management, security management, remote management, Just-in-time compilation, code-enforced security type checking, and more. These can be called the lifeline of the Microsoft.NET framework.

In fact, we can see that the CLR is acting as a part of the management capabilities of traditional operating systems. Code under the CLR is called managed code, otherwise it is referred to as unmanaged code. We can also view the CLR as a technical specification that can be run with its support, regardless of the language in which the program is written, as long as it is compiled into Microsoft intermediate Language (MSIL), which enables the application to be independent of the language. There are currently up to twenty or thirty programming languages that support the CLR. The Microsoft intermediate language is the language of the PE file that we output from the compiler in the Microsoft.NET platform. It is the most complete language set of the Microsoft.NET platform, very similar to the assembly language on the PC. The Just-in-time compiler compiles the intermediate language into a cost-binary code at run time. It provides low-level technical support for the Microsoft.NET platform in multiple languages. In addition, as needed, the Microsoft.NET Just-in-time compiler provides economical just-in-time compilation and installation-time compilation techniques in exceptional cases.

The purpose of the CLR is to provide first-order support for component-based programming directly in the application's operating environment. Just as you add a pair of Windows, direct support for controls, graphics, and menus, adding the underlying structure for message-based programming, and adding abstract content to support device independence, the CLR directly supports components (including properties and events), objects, inheritance, polymorphism, and interfaces. Direct support for properties and events makes component-based programming simpler, without the need for special interfaces and adaptive design patterns. While the component is running, the CLR is responsible for managing memory allocations, starting and aborting threads and processes, hardening safety factors, and also adjusting the satellite configuration of any other components involved in the component. Serialization support allows you to manipulate components stored on disk in a variety of formats, including soap based on industry-standard XML. The CLR provides a powerful, coordinated way to handle error conditions. Each module has built-in complete metadata, which means that features such as dynamic creation and method invocation are easier and more secure. Mapping even allows us to flexibly create and execute code. We can control the version of the components that the application uses, which makes the application more reliable. Component code is a processor-independent and easily verifiable intermediate language (IL), not a particular machine language, which means that components can run not only on a variety of computers, but also ensure that they do not overwrite memory that they do not use, and do not potentially cause system crashes. The CLR determines to them the appropriate level of trust based on factors such as the source of the managed components (such as from the Internet, corporate LANs, local machines), so that the CLR qualifies them for certain sensitive operations such as reading files, modifying the registry, and so on, based on their degree of trust. Strict security checks on code types with a common type system (Common type systems, abbreviated as CTS) avoid the possibility of type mismatch between different components. All programming under the CLR is done around the component.

It is worth noting that the CLR is typically hosted in other High-performance server applications, such as Internet Information Server (IIS), Microsoft SQL Server. This allows us to leverage the common language runtime's many security, efficient advantages to deploy its own business logic.

Memory management

The most important thing the CLR has to do with programmers is its memory management capabilities, so much so that we need to list it separately. It provides a high-performance garbage collection environment for applications. The garbage collector automatically tracks the objects of application operations, and programmers no longer have to deal with complex memory management. In some of the so-called masters who like to open their mouth to the bottom of the program, automatic memory management has always been the object of ridicule. Indeed, an automated memory manager designed for a common software environment will never be built on the hand-made custom tailored to a particular program. But the modern software industry is no longer a hundreds of line of code workshop operations, tens of thousands of lines of code, a large number of business logic is no longer the dexterity of the algorithm, but manageability, maintainable engineering code. Net/c# is not prepared for such a workshop master, C language is their beauty. In a Microsoft.NET managed environment, the CLR handles the memory layout of objects, manages references to objects, and frees up memory (automatic garbage collection) that the system is no longer using. This fundamentally solves the memory leakage and invalid memory reference problem which has plagued the software for a long time, which greatly reduces the programmer's development burden and improves the robustness of the program. In fact, we can't find the language instructions for memory operation or release in the managed environment at all. It is worth noting that microsoft.net applications can use managed data or unmanaged data, but the CLR cannot judge managed and unmanaged data.

The garbage collector is responsible for management. NET application memory allocation and release. When a new object is created with the Managed, the garbage collector allocates memory resources for the object in the managed heap (HEAP). As long as the memory space within the managed heap is available, the garbage collector allocates memory for each newly created object. When an application no longer holds a reference to an object, the garbage collector detects and releases the object. It is worth noting that the garbage collector does not start releasing work immediately when an object reference is not valid, but based on an algorithm to determine when to collect and what objects to collect. The memory resources of any one machine are always limited, and when the memory space in the managed heap is insufficient, the garbage collector initiates the collection thread to release the system memory. The garbage collector determines which objects are freed from memory, depending on how long the object is alive, and how many times the object has been collected. In macroscopic view, we do not know the exact behavior of garbage collection, but the Microsoft.NET class library provides us with some functions to control the garbage collection behavior, in some special cases, we need to do some limited operation.

The garbage collector does not mean that the programmer will ever be able to do this once and for all, if you are working on an object that wraps the underlying operating system resources such as files, network Connections, Windows handles, bitmaps, and so on, we still need to explicitly release these unmanaged resources. This is explained in detail in "The five-talk constructor and the destructor".