System.IO.FileNotFoundException for one of my dll's

I still have big problems running an assembly consisting of C# generated dll
and exe and VC++ (managed+unmanaged+mfc) generated dll.
On my development machine no problem, but on any other machine.

I get an System.IO.FileNotFoundException for one of my dll's.
The odd thing is that the file is right there, the file have the correct
version and in the error messages you can clearly see that he does know
where to look for the file.
So in theory this should work!!!!!!

I tried to create a config file, but it does not help much.
I also tried to copy to a local folder, but no help.
And I activated full trust for the domain and executable!

A screen dump (Exception converted to messagebox) can be found here:
http://www.obaeyens.com/Skyscan/DOTN...entProblem.jpg

Any tips how to track down the real error so I will never ever have this
problem again?

> I still have big problems running an assembly consisting of C# generated
dll

and exe and VC++ (managed+unmanaged+mfc) generated dll.
On my development machine no problem, but on any other machine.

......

MYSTERY SOLVED!!!!!!

I had one VC++ (managed+unmanaged+mfc) generated dll, calls
SkyscanLibBase.dll.
This one uses MFC distributed with VC++ 2002.

My program ctRepair.exe needs this SkyscanLibBase.dll.

Some time ago I discovered that in order to run SkyscanLibBase.dll, I needed
to provide the necessary dll's used by mfc (mfc70.dll, msvcp70.dll and
msvcr70.dll) because some computers does not have this MFC 70 installed!
(.NET 1.1 comes with MFC 71). And all seemed to work just fine with this
release mode.

But totday I was busy compiling the debug version, so I copied the MFC 70
(mfc70.dll, msvcp70.dll and msvcr70.dll) to that local folder. and THIS was
my mistake !
I should have used the debugging version of MFC 70 (mfc70d.dll, msvcp70d.dll
and msvcr70d.dll). Note the 'd'.

The confusing part was because the error appeared to be SkyscanLibBase.dll,
while in reality it were dll files used by SkyscanLibBase.dll.
You can find back the used dll's by using the dependency walker.

This all worked fine on some machines because these dll's were found in the
c:\winnt\system32 folder installed by some other program.
So I am finally ready to deploy my applications, and I am a very happy man
now. :-)