stringPath =@"C:\text.dll"Assembly Assembly=assembly.loadfile (path); Path="MyPhotoAlbum, version=5.1.0.0"; Assembly Assembly=assembly.load (path); byte[] B =file.readallbytes (path); Assembly Assembly=Assembly.Load (b); AppDomain Dom= Appdomain.createdomain ("function"); AssemblyName AssemblyName=NewAssemblyName (); Assemblyname.codebase=path; Assembly Assembly=Dom. Load (AssemblyName); Type[] Types=Assembly. GetTypes (); AppDomain.Unload (DOM);
application domain
The operating system and the runtime environment typically provide some form of isolation between applications. For example, Windows uses processes to isolate applications. This isolation is required to ensure that code running in one application does not adversely affect other unrelated applications.
Application domains provide isolation boundaries for security, reliability, versioning, and unloading assemblies. Application domains are typically created by the runtime host, which is responsible for booting the common language runtime before running the application.
Previously, process boundaries were used to isolate applications running on the same computer. Each application is loaded into a separate process, which isolates the application from other applications running on the same computer.
These applications are isolated because the memory addresses are process-dependent, and in the target process, memory pointers that are passed from one process to another process cannot be used in any meaningful way. In addition, you cannot make a direct call between two processes. You must instead use the proxy, which provides some degree of indirection.
Managed code must pass a validation process before it can run (unless the administrator has authorized the validation to be skipped). This validation process verifies that the code will attempt to access an invalid memory address? Are you trying to do something else that causes the process (the process where the code is running) to not work as expected? The code that passes this validation test will be considered type-safe. Because the common language runtime is able to verify that code is type-safe, it can provide an isolation level as large as the process boundary, with much lower performance overhead.
application domains provide a more secure, more versatile processing unit that can be used by the common language runtime to provide isolation between applications. You can run several application domains in a single process with an equal isolation level (in a separate process) without the overhead of inter-process calls or inter-process switching. The ability to run multiple applications within one process significantly enhances the scalability of the server.
Isolating applications is also important for application security. For example, you can run controls in several Web applications in a single browser process, while making these controls inaccessible to each other's data and resources.
The isolation provided by the application domain has the following advantages:
Errors that occur in one application do not affect other applications. Because type-safe code does not cause memory errors, using an application domain ensures that code running in one domain does not affect other applications in the process.
The ability to stop a single application without stopping the entire process. Using application domains allows you to unload code that runs in a single application
Note: You cannot unload a single assembly or type. Only the entire domain can be uninstalled
The relationship between the application domain and the assembly. Before you can execute code contained in an assembly, you must load the assembly into the application domain. Running a normal application causes several assemblies to be loaded into an application domain.
How the assembly is loaded determines whether the JIT-compiled code can be shared by multiple application domains in the process, and whether the assembly can be unloaded from the process.
If an assembly is loaded in a domain-neutral form, all application domains that share the same security grant set can share the same JIT-compiled code, reducing the memory required by the application. However, assemblies are never unloaded from the process.
If an assembly is not loaded in a domain-neutral form, it must be JIT-compiled in each application domain that is loaded. However, you can unload an assembly from a process by unloading all application domains that are loaded by the assembly.
We can tell that when we load an assembly by default in our program, because it is loaded in a program domain, the assembly will not be unloaded until the program exits, and we will be able to implement loading and unloading in the subroutine domain by creating a sub-program domain, which is described in the following assembly class loader domain
The Load method does not accept the specified path under the DLL to be used to load the assembly DLL that is already running, the specified parameters are generally name,version,id of the Assembly, and so on
Load (AssemblyName), or//////AssemblyName The assembly in the case of a given assembly .
Load (String)///assembly for specified information
Load (byte[])///load byte stream, this can not run
The LoadFile and LoadFrom methods are provided for very few scenarios where the assembly must be identified by the path, loading the DLL under the specified path, regardless of whether it is running or not.
Examples are as follows:
Examples of reflection calls are as follows
One of the simplest examples of C # reflection is to first write the class library as follows: namespace reflectiontest{public class Writetest {//Common method with parameters publicly void WriteString (s Tring s, int i) {Console.WriteLine ("WriteString:" + S + i.tostring ()); }//static method with one parameter public static void Staticwritestring (String s) {Console.WriteLine ("Staticwritestring:" + s); }//static method without parameters public static void Noneparawritestring () {Console.WriteLine ("noparawritestring"); }}} class testapp{public static void Main () {Assembly; Type type; Object obj; Used to test the static method object any = new object (); Specifies that the class library file must use an absolute path and cannot use the relative path of the Assembly.loadfile (@ "D:\Source code\00.c#sudy\01.reflection\01\reflecttest.dll"); The name of the namespace and class must be specified together with type =. GetType ("Reflectiontest.writetest"); /**//*example1---------*/MethodInfo method = type. GetMethod ("WriteString"); String test = "Test"; int i = 1; object[] parametors = new Object[]{test,i}; In Example 1 must instantiate the reflection to reflect the class, because themethod is not a static method. Create an object instance obj = the. CreateInstance ("Reflectiontest.writetest"); Executes a public method with parameters. Invoke (obj, parametors); Method. Invoke (Any, parametors);//exception: the class that reflects the reflection must be instantiated, because the method to be used is not a static method. /**//*example2----------*/method = type. GetMethod ("staticwritestring"); Method. Invoke (NULL, new string[] {"Test"}); The first parameter is ignored//for the first parameter is ignored, that is, we write nothing will be called,//even if we casually new a any such object, of course, this kind of writing is not recommended. But corresponding to the example 1, if you use an instance of type inconsistency when you invoke it, it will cause a runtime error. Method. Invoke (obj, new string[] {"Test"}); Method. Invoke (Any, new string[] {"Test"}); /**//*example3-----------*/method = type. GetMethod ("noneparawritestring"); An example of calling a parameterless static method, when two parameters are not required, is null. S method. Invoke (null, NULL); }}
C # assembly