Why. NET platform does not support Assembly offload (Assembly.unload)?

Tag: ETH trace causes the MSDN System Net assembly issue to be generated:

We know that reflection in the. NET platform provides information that dynamically gets members and members of each type in a program or assembly at run time, including classes, structs, delegates, interfaces, enumerations, and so on, so that our developers can use the information to construct and consume objects at run time. We know that reflection can get all the information we want by dynamically loading the assembly information in the Assembly.Load under the System.Reflection.Assembly namespace. So when we load the assembly dynamically and use it, we want to unload it and do not want to leave the spam in memory, when we find that assembly does not provide Assembly.unload method for us to unload the assembly dynamically, why?

First of all, we want to implement the Assembly.unload function, mainly to reclaim space and update the version of the two types of requirements. The former uses the Assembly to reclaim its resources, while the latter unloads the current version to load the updated version. For example, the dynamic update of the Assembly program used in the page is a good example of using ASP. However, if the Assembly.unload function is provided, some of the following problems are raised:

1. To ensure that the code addresses referenced by the code in the CLR are valid, special applications such as GC objects and COM CCW must be tracked. Otherwise, Unload a Assembly after a CLR object or COM component uses the code or data address of this Assembly, resulting in an access exception. In order to avoid this error tracking, is currently at the AppDomain level, if you want to join Assembly.unload support, the granularity of tracking must be reduced to Assembly level, although not technically impossible, but the cost is too high.

2. If Assembly.unload is supported, you must track the handle that each Assembly code uses and a reference to the existing managed code. For example, now that the Jiter is compiling the method, the generated code is in a unified zone, and each Assembly must be compiled independently if the unload Assembly is to be supported. In addition, there are a number of similar resource usage issues, which, if feasible, are more costly, especially in systems with limited resources such as WinCE.

The 3.CLR supports Assembly load optimization across the AppDomain, which is the optimization of domain neutral, allowing multiple AppDomain to share a single piece of code and speed up onboarding. The Unload domain neutral type code cannot be processed at this time. This also leads to the difficulty of realizing the complete semantics of assembly.unload.

Based on the above-mentioned readiness, dynamic uninstallation of assembly information is not currently supported.

For more detailed reasons, refer to the Great God's blog: https://blogs.msdn.microsoft.com/jasonz/2004/05/31/why-isnt-there-an-assembly-unload-method/

Why. NET platform does not support Assembly offload (Assembly.unload)?