We\'re currently testing Mono to see if our .NET DLLs will work for customers on Linux. Our DLLs provide components for Windows Forms. I placed the DLLs in the Debug direc
The likely issues are that the assembly is not put in the same directory as the program or that the case sensitivity of the assembly file name is not preserved when it was copied. For example, you may have a OUR.ASSEMLY reference, but the filename is OurAssembly.DlL or any other invalid case combination that people can come up with.
What Jonathan said is correct, you need to run the command as shown and it will produce copious amounts of information.
The assembly has a strong name, so it sounds like on Windows you have a dependency that is installed on the GAC. If "OUR.ASSEMBLY" is supposed to be there, run:
gacutil -i OUR.ASSEMBLY.dll
To install it. There might be other dependencies that OUR.ASSEMBLY.dll needs which is what JPobst' command would show.
uxtheme.dll
is the Windows theme engine, if I'm not mistaken. It's quite natural you don't have that in a non-Windows environment, so P/Invoking its exported functions is not directly possible.
You have two options here:
OnHandleCreated
method and replace the SetWindowTheme
call with something portable orlibuxtheme.so
that contains just this one function so mono can P/Invoke it.I recommend the first approach if possible, as you'd need to create that dummy libuxtheme.so
for every platform you're supporting. I.e., you'd have to make a libuxtheme.so
for x86 Linux, a libuxtheme.so
for x86_64 Linux, the same for FreeBSD, a libuxtheme.dylib
for Mac OS X and so on.
If OnHandleCreated
was generated by some UI designer or the like, you probably have to remove some widget themes the get rid of the call.
I'd test the DLL with MOMA (Mono Migration Analyzer) to see if it's using unsupported API's.
You can generally get more details on .dll loading errors by running with:
MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono myapp.exe