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
>
_______________________________________________
Mono-devel-list mailing list
[email protected]
http://lists.ximian.com/mailman/listinfo/mono-devel-list
