Bug 10468 - Attempting to obtain the CSharp CodeDomProvider since Mono 3.0.2 (4.5 profile) in embedded builds causes a System.Configuration.ConfigurationErrorsException
Summary: Attempting to obtain the CSharp CodeDomProvider since Mono 3.0.2 (4.5 profile...
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: 3.4.0
Hardware: PC Windows
: --- normal
Target Milestone: Untriaged
Assignee: Bugzilla
Depends on:
Reported: 2013-02-20 09:50 UTC by Filip Lundgren
Modified: 2017-02-10 08:04 UTC (History)
6 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and 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 Links.

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.

Related Links:

Description Filip Lundgren 2013-02-20 09:50:19 UTC
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.
Comment 1 Marek Safar 2013-02-20 16:31:22 UTC
I need info how to reproduce it.

Simply calling "var provider = CodeDomProvider.CreateProvider("C#")"  works
Comment 2 Filip Lundgren 2013-02-20 17:46:01 UTC
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)
Comment 3 Filip Lundgren 2013-03-03 23:19:28 UTC
Changed status.
Comment 4 Filip Lundgren 2013-03-30 12:21:16 UTC
bump, did anyone have a look at this?
Comment 5 Filip Lundgren 2014-06-22 10:58:53 UTC
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?
Comment 6 Andres G. Aragoneses 2015-01-15 05:11:26 UTC
Wasn't this fixed in https://github.com/mono/mono/commit/57f5187ad29a7913f083a659ea77d90eb8bad4d4 ?
Comment 7 jg23497 2015-02-09 07:32:25 UTC
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.
Comment 8 Andres G. Aragoneses 2015-02-09 07:45:36 UTC
> I used the mono-complete package and am using Ubuntu Server 14.04 64-bit

What version of mono does that package bring?
Comment 9 Andres G. Aragoneses 2015-02-09 07:48:24 UTC
> 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.
Comment 10 jg23497 2015-02-10 03:48:13 UTC
Having upgraded, and now using Mono version 3.12.0, the issue still occurs unfortunately.
Comment 11 Andres G. Aragoneses 2015-02-10 03:56:00 UTC
How did you upgrade?
Comment 12 jg23497 2015-02-10 04:04:00 UTC
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.
Comment 13 Damien 2015-03-27 09:57:42 UTC

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
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  x86
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen

Line in my code is :
Comment 14 Andres G. Aragoneses 2015-03-27 16:51:56 UTC
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.
Comment 15 Marek Safar 2017-02-10 08:04:08 UTC
Fixed in master