.NET dynamic loading assembly (1)

zhaozj2021-02-16  56

Let's first look at the .NET and the important concepts:

(1) The application domain, is represented by the AppDomain object, providing isolation, unloading, and security boundaries for execution managed code. Multiple application domains can run in a process; however, there is no one-to-one association between the application domain and the thread. Multiple threads can belong to an application domain, although the given thread is not limited to an application domain, but at any given time, the thread is executed in an application domain. The application domain is created by using the CREATEDOMAIN method. AppDomain instances are used to load and execute assemblies. When you no longer use Appdomain, you can uninstall it. The AppDomain implements a set of events that enable the application to respond when loading an assembly, uninstalling an application domain, or an unprocessed exception.

(2) The assembly is the generated block of the .NET framework application; the assembly constitutes a basic unit of deployment, version control, reuse, activation range control, and security permissions. The assembly is a collection of types and resources generated for collaborative work, which constitutes a logical function unit. The assembly provides the public language runtime to provide information sets to identify type implementations intend to simplify application deployment and resolve version control issues that may appear in component-based applications MS-Help: //ms.Netframeworksdk. CHS / CPGUIDENF / HTML / CPCONWHYUSEASEMBLIES.HTM

The assembly can be static or dynamic. Static assemblies can include .NET framework types (interfaces and classes), and resources of the assembly (bitmap, JPEG files, resource files, etc.). The static assembly is stored on the disk in the PE file format. You can also use the .NET framework to create a dynamic assembly, the dynamic assembly runs directly from memory and is not stored on the disk before execution. You can save them on the disk after executing the dynamic assembly.

(3) How to locate the assembly library

To successfully deploy the .NET Framework application, you must understand how the public language running library is positioned and binding assemblies that make up the application. By default, the running library tries to bind the original version of the assembly that generates the app. This default behavior can be overwritten by the configuration file settings.

When trying to locate the assembly and parse the assembly reference, the public language runtime will perform several steps. Each step is explained in the following sections. When describing how the runtime is positioned, "detection" is usually used; it refers to a set of tested methods used when using the name and regional positioning assembly.

(Use the Binding Log Viewer (FusLogvw.exe) included in the .NET Framework SDK to view the binding information in the log file)

When the runtime runs to resolve the reference to another, you will start positioning and binding to the process of the assembly. This reference can be static or dynamic. When generating, the compiler records a static reference in the metadata of the assembly list. Dynamic reference is dynamically constructed by calling various methods, such as system.reflection.Assembly.Load methods.

The preferred way to reference the assembly is to use full reference, including assembly names, versions, regional, and public key tags (if present). The run library will use this information to locate the assembly in accordance with the steps described later in this section. Whether the reference is a reference to a static assembly or a reference to the dynamic assembly, the running library uses the same resolution process.

The assembly can also be dynamically referenced by providing only some information about the assembly (for example specified only the assembly name) to the calling method. In this case, search assembly is only in the application directory, and other checks are not performed. You can use any method in different loading assemblies (such as system.reflection.Assembly.Load or AppDomain.Load) to partially reference. If you want to run the library to check the referenced assembly in the global program cache and application directory, you can specify a part reference with the System.Reflection.Assembly.LoadWithPartialName method. For more information on section bindings, see Some assemblies references. Finally, you can use the method such as System.Reflection.Assembly.Load to dynamically reference and only part of the information; then use the element in the application configuration file to limit the reference. This element allows you to provide full reference information in the application configuration file, including name, version, regional, and public key tag (if applicable). If you want to fully qualify a reference to an assembly in addition to the application directory, or if you want to reference the assembly in the global program cache, you want to easily specify a complete reference in the configuration file instead of the code, you can This technology is adopted.

Note that some of this type reference is not applied to assemblies shared by several applications. Because the configuration settings are applied to each application rather than each assembly, the shared assembly that uses this type of section will require each application that requires the shared assembly to have limited information in its configuration file. .

Renault use the following steps to parse the assembly reference:

1. Determine the correct assembly version by checking the applicable profiles (including application profiles, issuer policy files, and computer profiles). If the configuration file is on a remote computer, the run library must first locate and download the application configuration file.

2. Check if the program collection has been binded before, if it is bound, use the previously loaded assembly.

3. Check global assembly cache. If you find the assembly in it, the run library uses the assembly.

4. Press the following steps to detect the assembly:

a. If the configuration policy and the issuer policy do not affect the original reference, and the bind request is created using the Assembly.LoadFrom method, the runtime check position prompt.

b. If the code base is found in the configuration file, only the run library checks this location. If the detection fails, the runtime determines that the bind request has failed and no longer performs other probes.

c. Using the test method described in the detection section. If the assembly is not found after the detection is found, the RTM requests the Windows Installer Provider Set. It is used as a need to install function.

Note that you don't have a version of the assembly without a strong name, and the running library does not check the assembly without strong names in the global assembly cache.

转载请注明原文地址:https://www.9cbs.com/read-23012.html

New Post(0)