Using Precompiled .NET Assembly DLL in Mono?

Question

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 directory, added the references, and created a class deriving from a Windows Form. The class had run fine standalone, but after I added the DLL references and created one of our components (the intellisense worked fine), it compiles but will not run:

** (/home/aldwin/testMonoWF/testMonoWF/bin/Debug/testMonoWF.exe:26905): WARNING **: Could not load file or assembly 'OUR.ASSEMBLY, Version=1.0.0.1, Culture=neutral, PublicKeyToken=ATOKEN' or one of its dependencies.

Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'OUR.ASSEMBLY, Version=1.0.0.1, Culture=neutral, PublicKeyToken=ATOKEN' or one of its dependencies.
File name: 'OUR.ASSEMBLY, Version=1.0.0.1, Culture=neutral, PublicKeyToken=ATOKEN'

I looked at the properties of the assembly, and it is that version with that public key.

Is there a way for me to use these DLLs? What am I doing wrong?

EDIT:

According to MoMA, other than some [MonoTodo]s that have no bearing on the situation, there is one problem in three of the DLLs:

Calling Method | P/Invoke Method | P/Invoke Library
void OnHandleCreated (EventArgs) | int GoText/ComboBoxControl.SetWindowTheme (IntPtr, string, string) | uxtheme.dll

However, I opened one of our sample projects created with VS2008, pointed the reference to the DLL at the right place, and it worked fine. But I could not get the reference to work in a new project. Am I doing something wrong?

EDIT 2: To clarify, we don't want to recreate an existing windows application - we are simulating a customer creating a new application with our dll. I was just testing that to see if it was a dll problem. Since the VS-made application was able to find the dll and run successfully, it would seem it's not a dll problem. The new application is not calling anything the VS-created application doesn't.

Solution 1

I'd test the DLL with MOMA (Mono Migration Analyzer) to see if it's using unsupported API's.

Solution 2

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.

Solution 3

You can generally get more details on .dll loading errors by running with:

MONO_LOG_LEVEL="debug" MONO_LOG_MASK="dll" mono myapp.exe

Solution 4

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.

Solution 5

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:

1. Open up that OnHandleCreated method and replace the SetWindowTheme call with something portable or
2. Create a dummy libuxtheme.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.

View more solutions

Comments

[NickAldwin]

Just added the MoMA details above. It works fine with the sample app, though. Just not with the newly created app made with MonoDevelop.

[Michal Sznajder]

You don't (shouldn't) need to recreate the app in MonoDevelop. Mono should be able to run DLL's compiled in Visual Studio. I'd look at that ComboBoxControl.SetWindowsTheme call - that's making the p/invoke call, which means it won't be supported in Mono. Can you remove it, or not use that control?

[NickAldwin]

We don't want to recreate it - we are simulating a customer creating a new application with our dll. I was just testing that to see if it was a dll problem. Since the VS-made application was able to find the dll and run successfully, it would seem it's not a dll problem. The new application is not calling anything the VS-created application doesn't.

[NickAldwin]

Thanks for the answer, but after setting those environment variables mono still didn't give me any more information.

[NickAldwin]

We don't use the GAC, though.

[NickAldwin]

I made sure it was in the same dir and the same case, and it still resulted in the error.

[user1692901]

Sure, but you strongly named that assembly, so Mono is going to look up for it on the GAC. You can override this with "export MONO_PATH=DIR" for diagnostic purposes (it will command Mono to look up for the assembly in DIR, regardless of its strong name).

[lupus]

If you don't ewant to post the output log from setting the env vars, you might want to try and execute mono under strace: strace -f -e open mono yourtest.exe and see what file it is trying to load and where.