3. Component 3.1 What is component? Components are sometimes described as a logically .exe or .dll, it can be any application (with a primary entry point) or library. A component consists of one or more files (DLL, EXE, HTML files, etc.) indicating a set of resources, type definitions, and these types of implementations. One element can also include references to other components. These resources, types, and references are described in a data block called a list. The list is part of the component, so that components are described herein. An important aspect of components makes them part of a type of unique logo. The unique marker of the type is got together with the components and type names thereof. This means, for example, if the element A outputs a type called T, the component B outputs a type also known as T, and the .NET runtime will be considered a completely different types. In addition, don't confuse the components and namespaces - namespace is just a hierarchical approach to the organization type name. For running libraries, the type name is the type name, whether or not the name. From the running library, it is the only type of the type name (regardless of the type name belonging to which name space). The components are also important in the security of .NET - Many security limits are implemented on the boundary of the component. Finally, the component is the version controlled in .NET - see below for details. 3.2 How to create components? The easiest way to create components is to use the .NET compiler directly. For example, the following C # program: Public class ctest {public ctest () {system.console.writeline ("Hello from ctest");}} can be compiled into a library element (DLL): CSC / T: library ctest. Cs You can see the contents of the components by running the "IL Anti-Disassembly" tool belled in .NET SDK. In addition, you can also compile your source code into modules, then use the component connector (Al.exe) to combine the module into a component. For the C # compiler, the / target: Module switch can specify a module instead of the component. 3.3 What is the difference between private components and shared components? Spatial allocation and visibility: Private components are usually used by an application, which is stored below this application or subdirectory below. Sharing elements are typically stored in a global component buffer, which is the storage of components maintained by .NET running. Sharing elements are usually the code base to be used in many applications, such as .NET Framework classes. Version Control: The runtime is only implemented on the shared component, not the private component. 3.4 How does the component find each other? By looking for a directory path. There are several factors that affect the path (such as AppDomain host, application profile, etc.), but for private components, search paths are usually the application's directory and their subdirectory. For shared components, search paths are usually the same as private components, plus shared component buffers. 3.5 How does the component version work? Each component is represented by a version number called a compatibility version. Similarly, references to components (from another component) include names and versions of the referenced components. The version number has four digital parts (for example, 5.5.2.33). Elements that are not the same in the first two parts are considered incompatible. If the top two are the same, the third part is different, and components are considered "possible." If only the fourth part is different, the component is considered compatible. However, this is just the default guidelines - is the scope of the version policy decision to apply these rules. Version Policy can be specified in the application configuration file. Remember: The version control is only for shared components, not the private component.
