Sitting in relative obscurity since 2007…
[Updated 2/11/09: Included information about my experience in making a fresh build on a fresh install of Leopard]
Getting a Macintosh to serve up ASP.NET content is actually pretty simple. Mono's primary support for ASP.NET comes through an Apache plugin called mod_mono. This is very good news for the Mac user because Apache version 1.3 comes as part of Tiger. As long as you don't need to run other plugins that require newer versions of Apache (like Subversion), setting up ASP.NET on a Mac could scarcely be easier.
Prerequisites:
~/src/mono
)Here's what you need to do:
~/src/mono
.svn checkout svn://anonsvn.mono-project.com/source/trunk/mod_mono
.~/src/mono/mod_mono
and run the command ./autogen.sh --prefix=/Library/Frameworks/Mono.framework/Versions/Current
.autogen.sh
and configure
were failing because a tool named libtoolize
was renamed to glibtoolize
, and the configuration scripts were not configured to handle this. You can fix the problem either by creating an alias for libtoolize
or by editing the single line in autogen.sh
that refers to libtoolize
to point to glibtoolize
, instead; furthermore, based on what I read here, it seems that the configuration script fails to detect the 64-bit architecture on some Macs. If this happens to you (you'll know because Apache will fail to start up), run CFLAGS="-m64" ./autogen.sh --prefix=/Library/Frameworks/Mono.framework/Versions/Current
followed by a make clean
and make
.make && make install
. Note that you will probably need elevated permission to complete the installation ste./etc/httpd/httpd.conf
and add this to the end of the file: Include /private/etc/httpd/mod_mono.conf
. Update: in Leopard, this is /etc/apache2/httpd.conf
.At this point, you should have basic support for ASP.NET on your Mac. The last step that you performed turned on Apache, which by default will look for content in /Library/WebServer/Documents, and putting aspx files ino this folder should result in them being handled by mod_mono.
It should be noted that many applications will require more advanced setup than this (for example, applications like the CruiseControl.NET web dashboard want to be able to handle all web requests for their directory, not just the ones pointing to aspx files), but this is a topic for another post.