This is Xamarin's bug tracking system. For product support, please use the support links listed in your Xamarin Account.
Bug 2876 - fastcgi-mono-server4 fails with exception in git master
Summary: fastcgi-mono-server4 fails with exception in git master
Alias: None
Product: Class Libraries
Classification: Mono
Component: Sys.Web (show other bugs)
Version: unspecified
Hardware: PC Linux
: High normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-01-13 04:45 UTC by Timotheus Pokorra
Modified: 2012-02-01 17:11 UTC (History)
5 users (show)

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

lighttpd config file for fastcgi (2.08 KB, application/octet-stream)
2012-01-13 04:45 UTC, Timotheus Pokorra

Description Timotheus Pokorra 2012-01-13 04:45:03 UTC
Created attachment 1180 [details]
lighttpd config file for fastcgi

Using mono and xsp built from git master (today, 1079d0d03c926e9125605e0bb9d56b40cbd3350f).

When I open a simple Hello World aspx file, with fastcgi-mono-server4 and lighttpd, with no web.config file, I get the exception below in the log file.
If I use fastcgi-mono-server2 it works.

Looking at the code, it is this line:
System.Configuration.ConfigurationManager.AppSettings ["MonoServerDefaultIndexFiles"]

Is there something wrong in the machine config file, or in my lighttpd config file? Help is much appreciated. Mono 2.10.8 works fine with fastcgi-mono-server4, but it is missing a bug fix that has been committed to master but not to the 2.10 branch as it seems (needed for Ext.Net).

log file:
[2012-01-13 10:33:48Z] Notice  Beginning to receive records on connection.
[2012-01-13 10:33:48Z] Error   ERROR PROCESSING REQUEST: System.TypeInitializationException: An exception was thrown by the type initializer for Mono.WebServer.FastCgi.WorkerRequest

Server stack trace:
  at Mono.WebServer.FastCgi.ApplicationHost.ProcessRequest (Mono.WebServer.FastCgi.Responder responder) [0x00000] in /home/timotheusp/xsp/src/Mono.WebServer.FastCgi/ApplicationHost.cs:47
  at (wrapper remoting-invoke-with-check) Mono.WebServer.FastCgi.ApplicationHost:ProcessRequest (Mono.WebServer.FastCgi.Responder)
  at (wrapper xdomain-dispatch) Mono.WebServer.FastCgi.ApplicationHost:ProcessRequest (object,byte[]&,byte[]&)

Exception rethrown at [0]:
 ---> System.InvalidCastException: Unable to cast object of type 'System.Configuration.DefaultSection' to type 'System.Collections.Specialized.NameValueCollection'.
  at System.Configuration.ConfigurationManager.get_AppSettings () [0x00000] in /home/timotheusp/mono/mcs/class/System.Configuration/System.Configuration/ConfigurationManager.cs:176
  at Mono.WebServer.FastCgi.WorkerRequest..cctor () [0x0002b] in /home/timotheusp/xsp/src/Mono.WebServer.FastCgi/WorkerRequest.cs:50
  --- End of inner exception stack trace ---
  at (wrapper xdomain-invoke) Mono.WebServer.FastCgi.ApplicationHost:ProcessRequest (Mono.WebServer.FastCgi.Responder)
  at (wrapper remoting-invoke-with-check) Mono.WebServer.FastCgi.ApplicationHost:ProcessRequest (Mono.WebServer.FastCgi.Responder)
  at Mono.WebServer.FastCgi.Responder.Process () [0x00058] in /home/timotheusp/xsp/src/Mono.WebServer.FastCgi/Responder.cs:90
[2012-01-13 10:33:48Z] Notice  Finished receiving records on connection.
Comment 1 Zoltan Varga 2012-01-13 17:12:27 UTC
-> Sys.Web.
Comment 2 Timotheus Pokorra 2012-01-25 15:34:44 UTC
I have found this bug:
which has a similar error message.
The related commit is, it was a change in mono/metadata/assembly.c that fixed it back then.

But when I look at the code, I cannot see if this is a similar problem again.
And I am not even loading a third party dll.
And my case works fine with xsp4, but not with fastcgi-mono-server4.
Comment 3 Timotheus Pokorra 2012-02-01 03:59:36 UTC
While learning all about the configuration files, I finally found a difference between master and branch 2.10:

in method GetSectionInstance before
 XmlTextReader r = new ConfigXmlTextReader (new StringReader (xml), FilePath);
I added some logging for FilePath:

This is what I get in 2.10:
GetSectionInstance /opt/mono-2.10/etc/mono/4.0/machine.config

and this on master:
GetSectionInstance /opt/mono-master/etc/mono/4.5/machine.config

I have already tried to specify the framework version for mono with parameter  --runtime=v4.0, but this did not make a difference.

Am I on the right track?
How can I switch to 4.0 config files? Would that make any difference?

Another lead that I have investigated:
First the similarities:
In Mono 2.10 built from tar file, the appdomain for fastcgi-mono-server4.exe calls mcs\class\System.Configuration\System.Configuration\ConfigurationManager.cs OpenExeConfigurationInternal, and the name for the config file is fastcgi-mono-server4.exe.config, with System.Configuration.ClientConfigurationSystem.
After this, when the new appdomain for the web application is loaded, the method  ChangeConfigurationSystem of ConfigurationManager is called, switching to System.Web.Configuration.HttpConfigurationSystem.
This is the same in git master as well.

Now the difference:
git master calls OpenExeConfigurationInternal again, and loads the web.config file from the directory of the web application. But it seems, the file is not loaded properly, and just returns a default file, without the required sections and name/value pairs.

I am quite lost, and would like to get this solved.
If you have any ideas for even a dirty fix, I would be happy with that.
Thank you for reading this!
Comment 4 Timotheus Pokorra 2012-02-01 04:26:40 UTC
by the way, the assemblies loaded into the appdomain for the web application are in master:

Loaded: Mono.Web, Version=, Culture=neutral, PublicKeyToken=0738eb9f132ed756
Loaded: System.Xml, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
Loaded: System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
Loaded: System.Core, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089
Loaded: System.Configuration, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Loaded: System.Web, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Loaded: Mono.Security, Version=, Culture=neutral, PublicKeyToken=0738eb9f132ed756
Loaded: mscorlib, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089

So for the assemblies the 4.0 framework is used, but not for the config files? On the other hand, the config files of 4.0 and 4.5 are not much different, and even copying them does not resolve the issue.
Comment 5 Miguel de Icaza 2012-02-01 10:27:15 UTC

Can you look at this problem with the 4.0 vs 4.5 profiles?

This is a problem with configuration files, should we map 4.0 code  to go to the 4.5 directory instead?

Thanks for tracking this down Timotheus
Comment 6 Marek Safar 2012-02-01 12:04:45 UTC
OK, I'll try to investigate but the most likely source is that the net_4_5 directory should not exist at all (I told grendel not to copy it)


Loaded: Mono.Web, Version=, Culture=neutral,

means nothing both 4.0 and 4.5 has identical version info. Is there easy way to reproduce it ?
Comment 7 Miguel de Icaza 2012-02-01 12:14:16 UTC
Marek Habersack, can you discuss this topic with Marek Safar and sort this out?
Comment 8 Timotheus Pokorra 2012-02-01 12:15:17 UTC
I do not know if this 4.0 and 4.5 thing is really the source of the problem.

To reproduce:
If you use the lighttpd configuration in the way it is described on the page, and I have also attached my fastcgi config file for lighttpd, you can even work with no web.config, but get the error described above. 

So the test case is quite simple.

FastCGI does not work at all, I think. I tried with NGinx as well, but did not investigate that further.

Somehow the config files get confused.

Thanks guys for looking into this, this is greatly appreciated!
Comment 9 Marek Habersack 2012-02-01 13:00:30 UTC
the net_4_5 directory must stay until a runtime fix is implemented. Removal of the directory will break resource compilation, satellite assembly compilation and execution of 400+ sys.web* tests. The problem is that runtime must transparently perform all the mappings between 4.5 and 4.0 assemblies (especially that they all have the same versions)
Comment 10 Marek Safar 2012-02-01 14:15:44 UTC
OK, I did some digging and found out it's XSP problem.

It installs


into mono/lib/4.0 directory which is wrong (4.0 directory should contain only metadata dlls)

Moving these 3 exe(s) into /mono/lib/4.5 directory and fixing mono/bin/mod-mono-server4|fastcgi-mono-server4|xsp4 scripts to point to lib/4.5 makes fastcgi-mono-server4 work again.
Comment 11 Marek Safar 2012-02-01 15:09:50 UTC
Fixed in xsp master
Comment 12 Timotheus Pokorra 2012-02-01 17:11:40 UTC
Thank you so much, this works now!

Note You need to log in before you can comment on or make changes to this bug.