Unloading Assemblies in .NET (Hint: YOU CAN’T)
C# is a wonderful language. It is my favorite. You can do all sorts of cool things in it. Except unload a motherfucking DLL.
Microsoft and all of their shills say that you can. But you have to do it the “safe” way. You see – once an Assembly is loaded into your AppDomain, it can never be unloaded. They recommend this solution: load Assembly into NEW AppDomain and unload THAT AppDomain when you are finished with the Assembly. Which would be fine if: 1. it worked seamlessly, 2. it performed reasonably, and 3. it were implemented on the Compact Framework.
You see, in order for two AppDomains to communicate, objects are marshalled back and forth using various proxies and byte copying mechanisms. Some of this works transparently, a lot of it just plain sucks. You can find a good example of it at this website.
The whole idea was concocted by assholes. “Sandbox!! You must sandbox teh code and keep it separate and blah di blah blah untrusted blah safe blah blah references blah blah.” Nothing like a little piss in the sandbox. Actually, their real reasoning is this:
- First off, you are running that code in the app domain (duh!). That means there are potentially call sites and call stacks with addresses in them that are expecting to keep working. Have you ever gotten an access violation where your EIP points to 0x???????? That is an example where someone freed up a DLL, the pages got unmapped by the memory system, and then you tried to branch to it. [...] This tracking is handled today around an app domain boundary. Tracking it at the assembly level becomes quite expensive.
- Say you did manage to track all handles and references to already running code by an assembly. [...]The JIT’d code is still allocated in the app domain loader heap [...] So this one is solvable and just falls into the work column with a small hit on allocation and jitted method locality (probably not enough to measure).
- The final issue relates to code which has been loaded shared, otherwise more formally know as “domain neutral” [...] On the other hand, the code must therefore be tracked in all app domains it has ever been loaded into before it can be freed. With the current v1.0 and v1.1 product it is not even possible to unload domain neutral code because of these restrictions.
In other words:
- We’re too fucking lazy to figure out an efficient way to produce a killer feature.
- We’re too fucking lazy to actually do our job.
- We’re too fucking lazy to enhance our product.
Seriously, this has been a problem for 5 years now. It was easy as shit in C and C++ to write a plugin infrastructure – but now, because we have to be ‘safe’ we can’t do this? For fucksake, I’ll mark my code as unsafe if I could just do this. This is a step backward! Modern programming languages have been able to handle plugins forever, but some genius decided to unnecessarily complicate things with AppDomain communication.
Go die and kill yourself, you silly fucks.
Filed by xtravar at June 27th, 2008 under programming