AAAGHGH. I hate assembly loading in .NET. The whole system is designed for shipping software, and all the great advice out there is from the point of view of shipping software.
So what if you're running a web application, where you completely control the hardware and software, and there's almost no need for versioning, and the act of trying to make strongly named assemblies go properly is a total nightmare? Oh, you're screwed then. You will have nightmares that put the worst java classloader problem you've ever seen look like a nice walk in the park on a warm spring day.
And yes, I'm even including the time that the people before us had tossed nearly everything into the system classpath, had each EJB configured as it's own application so it had it's own classloader, some classes -were- required to be in the system classpath (Weblogic custom realm) but they used some objects from the EJB and web tier, web-layer objects (like HttpSession) were being passed into session EJB's as arguments so servlet code had to be available to EJBs, and we had to unravel the whole thing to be able to have our sandboxes able to update without restarting weblogic.
Walk in the park compared to what we're going through right now. Load() vs. LoadFrom() context. Way too much magic.
Update: Remembered some more stuff about why that java situation was still a pain, but it was still conceptually easier to understand what was going on than this issue is.
This is Rob Meyer's weblog, a weblog focused on software development and system administration based on 10 years of experience. Want to explore further? You can find out more me or see the rest of my website.
Wondering if I've written on something in particular? Try searching:
You might want to take a look at some of the more requested postings (as judged by incoming traffic):
Want more? Subscribe to this site 
or contact me at rob at big dis dot com.
See my writings on: