C # Talking about the processing of the reflected memory,

C # Talking about the processing of the reflected memory,

Due to the project requirements of the company, I made a client framework using the reflection mechanism of c. All the modules in the client are provided in a certain FORM, such as FORM and UserControl. The process is very simple and pleasant. The specific process is as follows:

1. Collect customer requirements

2: Sort requirements to form necessary documents

3: Get the interface style of the program through discussion.

4: The UI Designer designs a specific interface.

5: encapsulate necessary services as needed (we can use the c # WCF Service or JAVA Service)

6. Create a service management framework

7: controls to be used by the encapsulation Program

8: Compile the client framework

9: Writing module

10: Load for testing

The above is a simple development process, which includes a lot of sweat. A good program must satisfy the most basic detachable and pluggable requirements. Plug-in architecture. Both the client and server must adopt plug-in management.

There is a big problem in the c # client framework using Microsoft's reflection and factory model mechanism. It is impossible to release the memory when the reflected DLL is loaded into the memory. The memory is released only when you close the program, which has a major defect. I have also found many solutions on the Internet, but none of them can be successful. The most typical method is to uninstall the plug-in. In this way, although some memory can be released, all the memory cannot be released. When I talked to many programmers about this, they said they would release everything that can be released. However, even if you do this, you cannot achieve a very good release effect (maybe my level is not good ). Let's talk about the memory release of VS today. The memory of VS is managed to use and release resources. For unmanaged resources, they can be released through destructor and other methods. Microsoft has not provided a good method for reflection. If programmers have a good way to learn from us, it will be a great success.

I have mentioned above that the plug-in can be detached to release some of the memory, and the effect is also good. However, some controls written by the WCF Service do have some problems in the remote mode. The specific implementation code is as follows:

Internal class AssemblyLoader: MarshalByRefObject, IDisposable
{
# Region class-level declarations
Private Assembly a = null;
# Endregion


# Region constructors and destructors
Public AssemblyLoader (string fullPath)
{
If (a = null)
{
A = Assembly. LoadFrom (fullPath );
}
}


~ AssemblyLoader ()
{
Dispose (false );
}


Public void Dispose ()
{
Dispose (true );
}


Private void dispose (bool disposing)
{
If (disposing)
{
A = null;
System. GC. Collect ();
System. GC. WaitForPendingFinalizers ();
System. GC. Collect (0 );
}
}
# Endregion
# Region public functionality
Public object GetObject (string typename, object [] ctorParms)
{
BindingFlags flags = BindingFlags. CreateInstance | BindingFlags. Instance | BindingFlags. Public;


Object o = null
;
If (! = Null)
{
Try
{
O = a. CreateInstance (typename, true, flags, null, ctorParms, null, null );
}
Catch
{
}
}
Return o;
}


Public object GetObject (string typename)
{
Return GetObject (typename, null );
}
# Endregion

 

Public class ObjectLoader: IDisposable
{
// Essentially creates a parallel-hash pair setup
// One appDomain per loader
Protected Hashtable domains = new Hashtable ();
// One loader per assembly DLL
Protected Hashtable loaders = new Hashtable ();


Public ObjectLoader ()
{}


Public object GetObject (string dllName, string typeName, object [] constructorParms)
{
AssemblyLoader al = null;
Object o = null;
// Type t = null;
Try
{
Al = (AssemblyLoader) loaders [dllName];
}
Catch (Exception ){}


If (al = null)
{
AppDomainSetup setup = new AppDomainSetup ();
Setup. ShadowCopyFiles = "true ";
AppDomain domain = AppDomain. CreateDomain (dllName, null, setup );
Int key = 0;
Foreach (DictionaryEntry de in domains)
{
If (de. Key. ToString () = dllName)
{
Key ++;
Break;
}
}
If (key = 0)
{
Domains. Add (dllName, domain );
}
Object [] parms = {dllName };
BindingFlags bindings = BindingFlags. CreateInstance | BindingFlags. Instance | BindingFlags. Public;
Try
{
// Al = (BCFrameWork. Client. ClientInfrm. AssemblyLoader) domain. CreateInstanceFromAndUnwrap (
// "Loader. dll", "Loader. AssemblyLoader", true, bindings, null, parms, null );
Al = (AssemblyLoader) domain. CreateInstanceFromAndUnwrap (
"BestelLoadDll. dll", "BestelLoadDll. AssemblyLoader", true, bindings, null, parms, null, null );
}
Catch
{
}
If (al! = Null)
{
If (! Loaders. ContainsKey (dllName ))
{
Loaders. Add (dllName, al );
}
}
}


If (al! = Null)
{
O = al. GetObject (typeName, constructorParms );

}
Return o;
}


Public void Unload (string dllName)
{
If (domains. ContainsKey (dllName ))
{
AppDomain domain = (AppDomain) domains [dllName];
AppDomain. Unload (domain );
Domains. Remove (dllName );
}
}


~ ObjectLoader ()
{
Dispose (false );
}


Public void Dispose ()
{
Dispose (true );
}


Private void dispose (bool disposing)
{
If (disposing)
{
Loaders. Clear ();
List removeobj = new List ();
Foreach (object o in domains. Keys)
{
String dllName = o. ToString ();
Removeobj. Add (dllName );
}
Foreach (string item in removeobj)
{
Unload (item );
}
Domains. Clear ();
System. GC. Collect ();
}
}
}

The call method is very simple. If you understand reflection, you will know how to call it. This method can meet the needs of normal user controls for remote reflection loading, but there is still no way for some special user controls.