. NET Architecture

This article is discussed as a whole based on. NET 4.0. NET Framework, from a new point of view to the more closely related to the security of the place to introduce. Because the nature of the book is different from the programming tutorials, many of the details can only be briefly summed up or slightly off, there are puzzled readers also hope that a lot of forgive and find relevant information on their own cultivation.

This article from. NET security, mainly introduces the common language runtime (CLR), Common type Systems (CTS), Common Language Specification (CLS), intermediate language (IL), Framework class Library (FCL), base Class library (BCL), Just-in-time compilation (JIT) and precompilation, and Dynamic Language runtime (DLR), Detailed parsing from the bottom.

1.1 Common Language runtime

The common language runtime (Common Language RUNTIME,CLR) provides a managed runtime environment for the. NET framework that runs managed code, security checks, garbage collection, and so on. This section provides an overview of the runtime, and security-related details are detailed in subsequent chapters.

Microsoft has created very convenient conditions for developers to develop programs that are run by the CLR, and the development tools and compilers are constantly upgraded, with rich documentation in detail. All aspects of net development. Code developed using a CLR-based language compiler is called managed code. Managed code has many advantages, such as cross-language integration, cross-language exception handling, enhanced security, versioning and deployment support, simplified component interaction models, debugging and Analysis Services, and more.

To enable the CLR to provide services to managed code, the language compiler must generate some metadata to describe the types, members, and references in the code. Metadata is stored with the code, and each loadable CLR portable execution (Portable executable,pe) file contains metadata. The CLR uses metadata to find and load classes, to schedule instances in memory, to resolve method calls, to raw machine code, to enforce security, and to set run-time context boundaries.

The CLR handles object layouts automatically and manages object references, which are freed when objects are no longer used. The objects that implement lifetime management in this way are called managed data. If you write code that is managed code, you can use managed or unmanaged data in a. NET framework application, or use both of these data. Because the language compiler provides its own type (such as primitive types), you may not always know (or need to know) whether the data is managed.

With the CLR, you can easily design components and applications that object can interact across languages. In other words, objects written in different languages can communicate with each other, and their behavior can be tightly integrated. For example, you can define a class, then derive another class from the original class using different languages or call methods of the original class, or you can pass an instance of a class to a method of another class written in a different language. This cross-language integration is possible because CLR-based language compilers and tools use common type systems defined by the CLR, and they follow the rules of the CLR about defining new types and creating, using, maintaining, and binding to types.

All managed components have information that generates the components and resources on which they are based, and this information forms part of the metadata. The CLR uses this information to ensure that a component or application has a specified version of all of its required content, making it less likely that the code will break due to some unsatisfied dependencies. Registration information and state data are no longer stored in the registry (because it is difficult to establish and maintain this information in the registry). Instead, information about defining types (and their dependencies) is stored with the code as metadata, which greatly reduces the complexity of component replication and removal tasks.

The way language compilers and tools expose CLR functionality is not only useful but intuitive to developers. This means that some features of the CLR may be more prominent in one environment than in another, and the experience of the CLR depends on the language compiler or tool being used.

1.2 Public type System

As we all know, every programming language has its own type system, but readers with a little exposure to different languages will find that there are many similarities or similarities in the type systems of various languages. NET abstracts a complete set of common type systems (CTS) using a variety of language-similar features to make all types independent of their source language. The CTS forms the basis of the. NET Framework's common language runtime, the most important of which is the multilingual support of the. NET platform, and the alias is used instead of the underlying data type of. NET for each language running on the. NET platform in order to maintain its own grammatical characteristics. The introduction of CTS solves many problems caused by various modules developed by multi-language collaboration.

1.2.1 CTS Basic Structure

The CTS not only defines all the data types, but also provides an object-oriented model and the standards that each language needs to comply with. The CTS can be divided into two broad categories: value types and reference types, while casts can also be cast between the two types, from value types to reference type conversions called boxing (boxing), and conversions from reference types to value types are called unboxing (unboxing).

The basic structure of the CTS, as shown in Figure 1-1, is that each type of CTS is an object and inherits from a base class System.Object.

Figure 1-1 CTS Basic structure