Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
GitHub or Developer Community with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
When creating a .NET runtime via embedding, the mono_jit_init() function does not initialize the AppDomain data structure(s) appropriately, such that AppDomain.CurrentDomain.SetupInformation.ConfigurationFile = null.
This causes a number of calls, such as Dns.GetHostName() to fail as this call looks up the ConfigurationFile and fails with the NPE. I filled a library bug for the NPE: https://bugzilla.xamarin.com/show_bug.cgi?id=9520. But it may be more appropriate to have mono_jit_init() adjust the AppDomain info appropriately.
I do the following:
_domain = mono_jit_init (bootassembly);
_core = mono_domain_assembly_open (_domain, bootassembly);
bootassembly is the path the the main assembly to be used. I would have thought
that mono_jit_init() would create an AppDomain and set the appropriate
Finally, this eventually calls C# code that invokes Dns.GetHostName(), which in turn fails with a NPE when trying to access AppDomain.CurrentDomain.SetupInformation.ConfigurationFile.
This problem only happens in mono 3.0.3 and not in 3.0.2 (but I think is because of changes in the C# libraries to use the config and not a change in the structures mono_jit_init() sets.
Calling mono_config_parse () first might fix this.
Unfortunately, changing the order did not solve the problem. I still get the NPE. I reverted to 3.0.2 (whose C# libraries are not dependent on this property of the AppDomain).
Until either the data structures from these calls are adjusted or the class libraries made to be resilient to missing config file, will not be able to take upgrades.
I suppose changing the C# side would be the easiest solution. I do not really understand what author "baulig" is doing with this config, otherwise would submit a patch here.
Seems to me that a dummy "null config" can be produced instead of throwing an exception if the AppDomain does not have an associated config file.
Worst case, may I suggest, short of a fix for the configuration, that lines 797 - 800 in:
be put in a try / catch and ipv6Supported be set to an appropriate default.
Please use the bootstrap code from the xamarin products as a reference on how to do it properly