[Mono-dev] using coreclr in mono embedding sample project
sebastien.pouliot at gmail.com
Mon Jun 15 09:18:13 EDT 2009
On Sun, 2009-06-14 at 01:34 +0200, Lucas Meijer wrote:
> In order to figure out how to properly use the new coreclr
> functionality, verifiers etc, I've taken the
> test-metadata.c sample that shows how to simply embed mono, and I'm
> adding some coreclr stuff to it.
> The sample works and runs fine with core clr disabled.
> If I add:
> mono_security_enable_core_clr ();
This is not enough. You are setting things in motion that have other
requirements - like having platform code that it can depend on. You'll
have, at least, to add a mono_security_set_core_clr_platform_callback
Please have a look at how moonlight initialize mono (and note that the
API is still subject to change).
> before mono_jit_init(), the mscorlib fails to load. When stepping
> trough the program with a debugger,
> the point where these two (with coreclr and without) diverge, is that
> line 465 of coree.c:
IIRC that file is part of the Windows-build only. As such it has never
been tested wrt coreclr.
> ModuleHandle = LoadLibrary(FileName);
> returns a valid handle when coreclr is turned off, and it returns 0 when
> coreclr is turned on.
> This is on windows, with r135921 runtime+corlib, using msvc2008 built
> mono using the stock msvc projectfile.
> I'm a bit surprised by this actually, as I wouldn't expect a call into
> the win32 api to behave differently based on the
> coreclr settings. (the FileName variable is identical in both cases).
I would expect the same. OTOH I don't know the code except that it
change how mono loads and execute .net applications under Windows.
> Am I doing something wrong?
> A verifier related question: in do_mono_image_load(), there are these
> mono_verifier_verify_pe_data(). this one requires image->raw_data_len
> to be set. (in verify_msdos_header)
> mono_verifier_load_pe_data(). this one actually sets
> image->raw_data_len. (in do_load_header)
> they're executed in the order above, which causes the first one to
> always fail for me.
> Bye, Lucas
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list