[Mono-dev] minimal setup for embedded application

[Jonathan Shore]

On further examination, it seems that when using mono_set_dirs (), is looking for:

	lib/mono/4.0
AND
	lib/mono/gac

Is there a way to avoid requiring the gac for an application with embedded mono?   A strace on all file open attempts shows that the gac is key to allowing the enumeration of types in System.Core.dll.   How do I work around this?  I don't want the file overhead of the gac if I can help it.  Just want to be able to indicate the 3 dependent assemblies.

Here are the calls (I have a very trimmed 2.10.6 distribution under "/home/jshore/Dev/EA/Isolated/dist"):

open("/home/jshore/Dev/EA/Isolated/lib/noarch/com.gf.core.dll", O_RDONLY) = 3
open("/home/jshore/Dev/EA/Isolated/dist/lib/mono/4.0/mscorlib.dll", O_RDONLY) = 3
...
open("/home/jshore/Dev/EA/Isolated/dist/lib/mono/gac/System.Core/4.0.0.0__b77a5c561934e089/System.Core.dll", O_RDONLY) = 3
open("/home/jshore/Dev/EA/Isolated/dist/lib/mono/gac/System/4.0.0.0__b77a5c561934e089/System.dll", O_RDONLY) = 3

Why doesn't mono look in lib/mono/4.0 for System.Core.dll?


On Apr 2, 2012, at 8:26 PM, Jonathan Shore wrote:

> Hi,
> 
> So I've been running some embedded apps with mono for a while successfully.   In each case have a full mono installation available locally on the box on which the application is run.
> 
> I needed to create a minimal mono environment  so can run the app with embedded mono, but without a full mono installation.   My application just depends on mscorlib.dll, System.Core.dll, and System.Data.dll (4.0).  I am testing on a virgin install of ubuntu 10.4, which for better or worse has an ancient mono installed (2.4.4), but would represent the typical target environment.  
> 
> I created a very minimal install and directed the mono VM to find what it needs in the application-local install, with:
> 
>    mono_set_dirs (myapp_lib, myapp_etc);
> This appears to work as expected.   Was able to load my assembly and start evaluation of a function.   However, ran into a problem when one of the functions attempts to use reflection to find a type.   I called Assembly.GetTypes() on the System.Core assembly, but throws the following exception:
> 
> searching assembly: System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
> exception: System.Reflection.ReflectionTypeLoadException: The classes in the module cannot be loaded.
>   at (wrapper managed-to-native) System.Reflection.Assembly:GetTypes (System.Reflection.Assembly,bool)
>   at System.Reflection.Assembly.GetTypes () [0x00000] in <filename unknown>:0 
> 
> (the "searching" message is a diagnostic from my code).   I believe it successfully located System.Core, but for some reason is failing to load the classes.   Previously I did not have System.Core.dll in the same directory with my application dll and it complained about not finding (so it has definitely found the dll).
> 
> Any ideas on what causes the System.Reflection.ReflectionTypeLoadException to be thrown?
> 
> My setup is as follows:
> 
> $ ls lib
> com.gf.core.dll  mono  System.Core.dll  System.Data.dll
> 
> $ ls mono
> 2.0 4.0
> 
> $ ls mono/2.0
> mscorlib.dll  System.Core.dll  System.Data.dll
> 
> $ ls mono/4.0
> mscorlib.dll  System.Core.dll  System.Data.dll
> 
> In my code, mono_set_dirs (...) is set to point to lib, and appears to pick up the dlls correctly.    Would the exception result from a DLL dependency or environmental element that is required?   Could the ancient mono 2.4.4 bundled with ubuntu be interfering?
> 
> 
> Thanks
> Jonathan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20120402/96dd4e4d/attachment.html>