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.
This issue started appearing in Mono 3.0.2, and still occurs in 3.0.4. The issue seems to be linked to this commit: https://github.com/mono/mono/commit/0b57238424265deb24a4c047a80da23501f9f240#commitcomment-2653846
This only occurs in the 4.5 profile, see the comment in the issue above for a stack trace.
I need info how to reproduce it.
Simply calling "var provider = CodeDomProvider.CreateProvider("C#")" works
Attempted to reproduce this in a minimal Mono embedding sample, and succeeded right away.
The sample can be viewed here, https://github.com/inkdev/Embedded-Mono-Sample.
It simply embeds Mono in a C++ application, loads a C# library which attempts to invoke CodeDomProvider.CreateProvider("csharp"), leading to the exception mentioned above.
(https://github.com/inkdev/Embedded-Mono-Sample/blob/master/Managed%20Source/ClassLibrary/EntryPoint.cs#L22, call TestJIT in the ClassLibraryManager constructor to reproduce)
bump, did anyone have a look at this?
Attempting to upgrade the project to Mono 3.4 now, and getting the same problem: http://pastebin.com/4zF02Hxb
This seems to occur to all embedded builds, is there a way to manually initialize system configuration?
Wasn't this fixed in https://github.com/mono/mono/commit/57f5187ad29a7913f083a659ea77d90eb8bad4d4 ?
The problem does indeed still occur:
"An exception was thronw by the type initializer for System.Net.ServicePointManager ---> System.Configuration.ConfigurationErrorsException: Error Initializing the configuration System. ===> System.ArgumentException: The 'ExeConfigFilename' argument cannot be null
I used the mono-complete package and am using Ubuntu Server 14.04 64-bit.
> I used the mono-complete package and am using Ubuntu Server 14.04 64-bit
What version of mono does that package bring?
> What version of mono does that package bring?
Actually, I know the answer to this: it is mono 3.2.8.
But the fix that states to fix this bug was committed later than this version was tagged. The first tagged version to, in theory, fix this bug, is 3.8. Please upgrade, and report back.
Having upgraded, and now using Mono version 3.12.0, the issue still occurs unfortunately.
How did you upgrade?
I started with a fresh VM (to avoid conflicts) and built Mono from the source tarball. Everything else seems fine - mono-test-install returns success.
I have the same problem, but on another method in my C# code.
I use mono embedded.
My env :
Ubuntu server 14.4.2 32 bits
Mono packages of distrib :
Mono JIT compiler version 3.2.8 (Debian 3.2.8+dfsg-4ubuntu1.1)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
LLVM: supported, not enabled.
Line in my code is :
Damien, if you look at earlier comments, you will notice that the fix for this bug is in Mono 3.8 or higher, but you're using Mono 3.2.8 which is older.
Fixed in master