[Mono-dev] File not found error when using Activator.CreateInstanceFrom()

[Jonathan Pryor]

On Jan 6, 2011, at 5:13 PM, mike wrote:
> Thanks for the reply. Not sure what you mean as I'm not doing a
> LoadLibrary().

Yes, "you" are: it's implicit to P/Invoke.  (OK, so .NET is doing it on your behalf under the covers, but a LoadLibrary() is still occurring.)

Since you're on Windows, LD_LIBRARY_PATH has no effect (that's a Unix environment variable).  Setting PATH might help; see:

	http://mono-project.com/DllImport#Windows_DLL_Search_Path

> Compile the sample code(s) above in this post for an example
> of how to produce the error.

The fundamental problem is that your example is still incomplete.  Providing a .zip may be more appropriate, but the fundamental question is this:  how _exactly_ you're compiling your native libraries?

For example, when I extract your source files from the relevant email and compile like this:

	CL /c MyEnviron.cpp
	LINK /DLL /OUT:Native\Environ.dll MyEnviron.obj

	CL /c MyLib.cpp
	LINK /DLL /OUT:Native\Test_Native.dll MyLib.obj Native\Environ.lib

	CSC app.cs /platform:x86

The above allows your code to work, but it took me an hour to re-learn enough CL+LINK to make it work.  (My first effort at `CL /LD /FoNative\Test_Native.dll MyLib.cpp` failed horribly, for reasons I can't fathom.  Thanks, Microsoft!)  I'm not sure why this would be failing under Mono, so that does appear to be a bug.

However, a workaround for mono is to place the .DLL files into the same directory as your .EXE, instead of into a "Native" sub-directory.  (At least, this works for me.)

Furthermore, your C# code appears wrong (or you're doing something different when compiling your native libraries).  Specifically:

		// Test Method
		[DllImport("Native\\Test_Native.dll",
		EntryPoint = "Test",
		ExactSpelling = false,
		CallingConvention = CallingConvention.StdCall)]
		static extern void _Test();		

Test_Native.dll!Test() will default to Cdecl calling convention, not StdCall, so your calling convention is wrong.  This often won't immediately break things (as .NET will occasionally detect the stack mismatch and fix it), but it can break things, and thus should be fixed.  I'm also not sure why you're setting ExactSpelling at all.

 - Jon