Programming · Summer of Code 2007

FastCGI ASP.NET Server Status Report 3

This is a status report for the week of June 11 – June 15. This week has been incredibly productive, culminating in a working ASP.NET server.


This week was an intense coding week:

  • I repackaged all the FastCGI specific code into its own library (Mono.FastCgi.dll)
  • I created Mono.FastCgi.Socket to wrap around System.Net.Sockets.Socket until the socket situation is fully resolved.
  • I copied Mono.WebServer into my project and have modified components to better work with the FastCGI server. (It isn’t necessary to modify the library to get the FastCGI server to work, but the changes allow the FastCGI server code to be cleaner.)
  • I created Mono.WebServer.FastCgi using code from XSP to produce a fully working ASP.NET server.
  • Lots of debugging.
  • Started documenting with /doc.

Session Test

Try it out for yourself:

  1. Check out the latest version from Subversion: <>
  2. Open the project in MonoDevelop.
  3. Build Mono.WebServer.FastCgi
  4. Enter FastCgi/Mono.WebServer.FastCgi/bin/Debug in the console.
  5. Run MONO_PATH=. mono fastcgi-mono-server.exe –port {port_number} –applications /:{path}
    where {port_number} is equal to the port you wish to run on. In my previous example, this was 1234
    and {path} is the path to the server root. In the case of OpenSuSE, this is “/srv/www/htdocs/”.
  6. Configure your web server to use FastCGI on {port_number} for the “aspx” extension.
  7. Enjoy.


With the first goal close to complete, I’m going to examine optimization a bit. (The current implementation loads the entire post data into memory.) In addition, I plan to get a working resolution to the socket issue that has been barring me from using Apache. Once these issues are resolved, I’ll begin work on the second goal: “A configuration page (aspx) and a web service to adjust or reset the server’s configuration remotely.”


The biggest challenge I ran into this week was in dealing with AppDomains, which I didn’t know existed until 1AM on Tuesday after a series of confusing errors. That issue has since been resolved and things have been running smoothly since.

A frustrating but workable problem I’m having is that the server runs in quite a few threads and sometimes when an exception occurs it doesn’t print to the standard output. It just hangs. Once you figure out the method which its hanging in, via –trace, you can wrap it in a try/catch and get the message.


Brian Nickel


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s