Analyze problems
Readers may think that all types of. NET must be inherited from system. Object. This understanding is too absolute and incorrect. In .net, the .netdesign group adds the noautoinherit switch for the compiler ilasm.exe of the intermediate language. When this switch is turned on, the compiler will not consider the type to inherit from system. object by default.
First, we will introduce the intermediate language compilation tool ilasm.exe. This is a compilation tool provided by. NET Framework. It is used to compile the intermediate language (msil) into executable PE files. This tool is very useful. It not only gives programmers the opportunity to directly write intermediate languages and compile them into PE files, but also provides another deployment method, that is, manually compile all the intermediate code and directly deploy the final machine code.
When noautoinherit is enabled, all generated types are inherited from system. object. object-type intermediate code, and the noautoinherit switch will generate a special non-parent class type.
In a fully-hosted single-language programming environment, designing a type that does not inherit from system. object does not bring any benefit. On the contrary, it may lead to various running errors that violate the conventional rules. The types that do not inherit from system. Object do not comply with CLS specifications, and unexpected exceptions occur in normal programs. However, to integrate other programming languages (such as C ++/CLI), such a built-in mechanism has its unique role. In general, the reader does not need or should not establish a system that does not inherit from the system. object type. However, in special environments, no code can inherit the object type from system. object guarantee, and even cannot trust the results of As, is, and other types of check syntax. The only thing a programmer can and must do is always prepare to capture unexpected exceptions.
Answer
The noautoinherit switch of ilasm.exe can generate a type not inherited from system. Object. This type is not a secure type and is not recommended. However, the existence of such a mechanism prevents programmers from arbitrarily regard any object as a subclass type of system. object when writing code.