0

Update:

Maybe a better question is: when using reflection, how to invoke DLL in DLL's home folder?

I am using reflection to load some Dlls and run them, which works great. But an issue pops up when my DLL need access external file.

Suppose I have a folder hierarchy like this:

myDLL/
     myDll.dll
     settings/a.txt
     settings/b.txt
     app.config

"myDll.dll" will use information from "a.txt", "b.txt" and "app.config".

My reflection program is in a separate folder. It will load "myDll.dll" and run some method in it:

Assembly.LoadFrom(@"path\to\mydll.dll");

But I got an error. This error is related to accessing "a.txt", "b.txt" and "app.config". The reason is these files are not in my reflection program folder,so when my reflection program loads "mydll.dll", "mydll.dll" will try to find "a.txt", "b.txt" and "app.config" under my current reflection program folder.

Is there a way to overcome this?

Thanks

Derek

derek
  • 9,358
  • 11
  • 53
  • 94
  • After your update: I don't know if could invoke a DLL in its home folder, as that would suggest a different working folder based on which DLL is executing. So you could either explicitly set the working folder (using Directory.SetCurrentDirectory) when working with the directory, but then you'd need to set it back when done. But if you control the other DLL, better to fix it to load it's files relative to the DLL's location - check out http://stackoverflow.com/questions/52797/how-do-i-get-the-path-of-the-assembly-the-code-is-in for an approach to that – Ian of Oz Oct 14 '16 at 00:56
  • @IanofOz Let us forget the update question now, what is the answer of my original question? Suppose I cannot change anything in the called DLL. – derek Oct 14 '16 at 01:08
  • @IanofOz "Directory.SetCurrentDirectory" cannot work. Just verified. – derek Oct 14 '16 at 18:26
  • Hmm, sorry I can't help more than that. Does it make any difference if you load the assembly in a separate AppDomain? – Ian of Oz Oct 16 '16 at 12:05

0 Answers0