C # Assembly Loading Method

1. Implicit Loading
Not explicitly loaded but referencedProgramSet, CLR will followGlobal Assembly Cache(GAC ),Working directory(Application directory) andPrivate path directoryTo find and load.

Ii. appdomain. Load Method
Load an assembly to a specific program domain, mainly usedUnmanagedCodeCall.

Iii. Assembly. Load Method
Load the Assembly by accepting an assembly identifier. If yesStrongly-named assemblyThe identifier includes the Assembly name, version, language culture, and public key tag. The load method will cause the CLR to find and load the Assembly according to the implicit loading policy.Weak naming assemblyIt is only the name of an assembly without the file extension. CLR will not search for it in GAC. If no private directory is specified, it will be searched in the working directory, such as assembly. load ("math "). The definition of the private directory can be specified in the configuration file. For example, the configuration file of the application myapp.execan be defined as myapp.exe. config. Content:

1. <? XML version ="1.0"Encoding ="UTF-8"?>
2. <Configuration>
3. <Runtime>
4. <Assemblybinding xmlns ="Urn: Schemas-Microsoft-com: ASM. V1">
5. <Probing privatepath ="App; app1 ;"/>
6. </Assemblybinding>
7. </Runtime>
8. </Configuration>

APP and app1 are two directories in the working directory. They are defined by probing to store the assembly to be loaded under this directory. If you use an assembly in a directory other than the working directory, you can use the codebase element to define it. You can find its attribute content on msdn.

Iv. Assembly. loadfrom Method
A parameter is the name or path of the file that includes the Assembly List, including the file extension. To load D: \ app \ math. dll, use the following statement:
Assembly A = assembly. loadfrom (@ "D: \ app \ math. dll ");
A is the loaded assembly.
However, this method has some disadvantages. I have a detailed description on msdn. One problem I encountered is that after loading an assembly in a non-working directory, an error occurred while using the objects in this Assembly in another assembly for deserialization. Solve the problem by using the Assembly. load method or placing the assembly in the working directory.

V. Assembly. LoadFile method
Load the content of the Assembly file in the specified path. Use the LoadFile method to load and check the Assembly that has the same identity but is located in different paths. Unlike loadfrom, LoadFile does not load the file into the loadfrom context, nor parse dependencies using the load path. LoadFile is useful in this restricted solution, because loadfrom cannot be used to load an assembly with the same ID but different paths. It only loads the first assembly.

Vi. Assembly. loadwithpartialname Method
Load the Assembly from the application directory or from the Global Assembly Cache using partial names. The parameter is the Assembly identifier, which contains the Assembly name (without the file extension ). The version, language culture, and public key of the Assembly are optional. When this method is executed, CLR first checks the xml configuration file of the application to search for the qualifyassembly element, if this element exists, it should be able to tell CLR how to map some assembly identifiers to fully qualified identifiers. CRL will look for the Assembly according to common rules. If this element does not exist, CRL searches the application's working directory and private path directory with the specified name. If not found, go to GAC.

VII. Call of traditional VC dynamic libraries
Call Win32 DLL through P/invoke

Using system. runtime. interopservices; // This is the assembly to be introduced when using dllimport

[Dllimport ("dbaccess. dll", charset = charset. Auto)]
Static extern ulong findapp (bool bistrue );
// Declare an external standard dynamic library, which is the same as WIN32API.

ArticleSource: http://blog.csdn.net/podded/archive/2008/10/27/3158687.aspx