IO Exception loading Assembly can't find file

Question

I am loading a Assembly at run time in my application:

FileStream lDLLStream = lDLLPath.OpenRead();
byte[] lDLLArray = new byte[lDLLStream.Length];
lDLLStream.Read(lDLLArray, 0, (int)lDLLStream.Length);

Assembly lAssembly = Assembly.Load(lDLLArray);

However, I am getting the following exception:

Could not load file or assembly 'UnityEngine, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

However, if I load a different DLL from the same directory that references both the DLL I was originally trying to load (and naturally UnityEngine as it has a dependency on that too), I get no error message.

In fact, at load you can see the second (working) DLL has in its referenced assemblies precisely:

UnityEngine, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null

So I am failing to see how if it can load the second DLL, what could be causing it to fail to load the first.

Some additional information: The first (non-working) DLL is precisely the DLL generated by Unity (3D game engine) whereas the second DLL is a project I created in the Unity solution.

My project is .NET 4.0 (and Unity is 3.5) but I tried setting my test DLL to compile to 3.5 and that didn't crash on load.

I don't know if this would be better asked on Unity Answers?

Update: OK maybe less odd that I thought. The second working DLL was only working since it wasn't using the DLL that it was failing to load so never got round to failing. Also, can get it to load the first DLL by dumping the Unity DLL in the executing directory, so I guess I just need to find a way of adding directories to where it should look.

Update 2: So I have "fixed" this issue by listening to

AppDomain.CurrentDomain.AssemblyResolve

And presenting a dialogue box to the user to find the missing DLL which has fixed the exception. I would appreciate knowing if there is a better way of doing this. Since the user is specifying custom DLLs so maybe this is the only reasonable thing to do. Otherwise, I will post this as an answer.

Answer 1

Basically my problem was a simple one hidden inside a (kind of) subtle one. The problem was just it didn't know where to look for the DLL. I was confused by the fact, I thought the DLL had already been loaded once. In fact, since the DLL was not used, it was never loaded so the working DLL never failed.

If people find this, I suppose my advice would be make sure the working DLL is actually loading the problematic DLL by using something from it.