mono_domain_set_config

[Numpsy]

Hi,

While trying to use Dubrovnik with some C# libs that are developed on Windows, I ran into a variant of the issue attached to mono/mono@57f5187 (i'm not trying to load any config myself, but i'm seeing the mentioned exception being thrown from the .net serialization lib when it tries to load its own config).

The issue is that the appdomain created by mono_jit_init doesn't have its config bits set up, and the fix is to call mono_domain_set_config() on it before using it. I was wondering if it would be useful to have a Dubrovnik wrapper for the function, but also if it would be worthwhile for the default environment to set it to a useful default given the possible issues with system libs if it isn't done?

Thanks.

[Thesaurus]

Hi

That sounds reasonable. At present I am utilising against an older version of Mono that doesn't define mono_domain_set_config(). Once I upgrade (which I need to do) this should be straight forward.

[Numpsy]

We started off using an old version, and then had to upgrade for various reasons (including getting the fix for this). I'm actually just getting it set up to use a build of 4.2.1 (seems like I need to pick up the El Capitan fixes).

[Thesaurus]

Yes. I am thinking the same thing. Are you running a 32 or 64 bit build of Mono. The current OS X MDK download is still 32 bit I think.

[Numpsy]

I'm using a 64bit build that I built myself.

[Thesaurus]

I have added a convenience method for mono_domain_set_config(). We can set this to a suitable path by default. I don't require this call myself so I am a bit fuzzy as to what to set the daft to. I presume that the managed layer needs read write access to the location and that it must be created if it doesn't exist.

[Numpsy]

I don't currently need to read/write any explicit settings myself, for now I just need the config machinery set up to avoid some problems when the mono libs themselves try to use it (and I think it may be ok if the file doesn;t exist when they only want to read it). If i do need to write things at some point, i'll probably set it to some app specific location.

When i was looking for info on this issue I saw some other callers point it at the machine config file at /Library/Frameworks/Mono64.framework/Versions/version/etc/mono/4.5/machine.config by default, which may be the sensible default? If not, maybe the directory the current app is running from?

[Numpsy]

on a related fyi, mono 4.0 will crash if you call domain_set_config with a config file name shorter than ".config" (fixed in 4.2 @ mono/mono@ac4cf68)

[Thesaurus]

My last commit to implement mono_domain_set_config was utter crap. Current commit should improve things.

By default the config file is loaded from /Library/Frameworks/Mono64.framework/Versions/Current/etc. If you are running Mono from outside /Library/Frameworks call DBManagedEnvironment -+ (void)configureAssemblyRootPath:(NSString *)monoAssemblyRootFolder configRootFolder:(NSString *)monoConfigFolder.

A normal user process certainly won't be able to write to /Library/Frameworks.
I am not quite sure under what circumstances you need to call mono_domain_set_config(). Perhaps ask on the Mono list for further clarification.

[Numpsy]

I'll update my build and give it a go.

I ran into problems in this area initialliy when I started getting exceptions thrown from the static constructor for XmlSerializer (https://github.com/mono/mono/blob/master/mcs/class/System.XML/System.Xml.Serialization/XmlSerializer.cs#L155), and this seems to be the 'fix' for that.
I just need to keep an eye on it I guess.

[Thesaurus]

If you look at the project README you can see that I have added a build script to ease building the Mono framework on OS X. I am currently targeting Mono 4.0.4.4.

[Numpsy]

I am currently targeting Mono 4.0.4.4.

Lucky me has just started submitting stubs for a few unimplemented functions in the Mono class libs. No idea what version that will end up in, but it's a learing experience at least ;-)

[Thesaurus]

I saw your exchange on the Mono list.
4.2 is in Alpha - http://www.mono-project.com/docs/about-mono/releases/4.2.0/.
Looks like this will pull in more MS reference source.
Might be worth checking if the functions you are targeting are now available in the reference sources.

Good luck!