dll's loaded through reflection - Phantom Bug

Question

Ok, I got a strange one here and I want to know if any of you have ever run accross anything like it.

So I've got this web app that loads up a bunch of dll's through reflection. Basically it looks for Types that are derived from certain abstract types and adds them to the list of things it can make.

Here's the weird part.

While developing there is never a problem. When installing it, there is never a problem to start with. Then, at a seemingly random time, the application breaks while trying to find all the types.

I've had 2 sites sitting side by side and one worked while the other did not, and they were configured exactly(and I mean exactly) the same.

IISRESET's never helped, but this did:

I simply moved all the dll's out of the bin directory then moved them back. That's right I just moved them out of the bin directory then put them right back where they came from and everything worked fine.

Any ideas?

Got some more info

When the site is working I notice this behavior: After IISRESET it still works, but recycling the app pool will cause it to break.

When the site is broken: Neiter IISRESET nor recycling the app pool fixes it, but moving a single dll out then back in fixes it.

Even More Info

So it turns out that IsAssignableFrom is not returning the correct value. I would not have believed it to be true, but I had my logger log the result and the 2 types, and it definitely returned the wrong value. The crazy thing is that the same dll will return different values at different times when comparing the same 2 types.

Yet More Info

The particular class that IsAssignableFrom fails on in located in a file with other classes. If I move the class to its own file, then everything works fine. However, if it is in the same file as other classes(even if it is in its own namespace block) then the Type reference is all wrong. The Type reference will have the correct name and methods, but it has trouble finding the correct constructor.

Answer 1

I can imagine there concurrency issues accessing the dlls. If multiple users are accessing the page at the same time, and one session attempts to access the dlls, gets exclusive access, all other sessions are failing. Of course, this requires exact timing only achieveable with multiple users, which is why this problem doesn't appear while testing or developing.

In other cases, add extended logging of the loading code, stacktraces of the exceptions being thrown.

Answer 2

This could be down to a locking issue. By default, all dlls in the bin directory are loaded by ASP.Net, even if they are not used in the web application. If you are trying to load the types from a specific dll, whilst at the same time ASP.Net is loading that dll into memory, you may get an error due to the file being in use. This may appear as the behaviour you have experienced as it will make a sort-of race condition, and will only present as an error if certain events happen whilst other certain events are happening - even if only a single user is using the site. This may also explain why you do not always get the behaviour.

To stop this, you could put your dlls that you dynamically load types from into a directory inside the bin directory and load them from there.

To be more precise with what the problem is, you would have to show us any error that you get when it fails to load the types (as it may be completely unrelated to a locking issue).

Answer 3

It is possible that two (or more) copies of the same assembly are getting loaded into memory. The best way to save yourself time and headache is to strong key your assemblies. If there is a strong naming key only one instance of the assembly will be loaded per appdomain.

More info on assembly binding contexts.