title: Using Precompiled .NET Assembly DLL in Mono?
body: <p>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:</p>
  
  <pre>
  ** (/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'
  </pre>
  
  <p>I looked at the properties of the assembly, and it is that version with that public key.</p>
  
  <p>Is there a way for me to use these DLLs?  What am I doing wrong?</p>
  
  <p>EDIT:</p>
  
  <p>According to MoMA, other than some [MonoTodo]s that have no bearing on the situation, there is one problem in three of the DLLs:</p>
  
  <pre>
  Calling Method | P/Invoke Method | P/Invoke Library
  void OnHandleCreated (EventArgs) | int GoText/ComboBoxControl.SetWindowTheme (IntPtr, string, string) | uxtheme.dll
  </pre>
  
  <p>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?</p>
  
  <p>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.</p>