Just got an e about ELMAH.  Yes, I think its pretty fine.  Saves a lot of time, does fine with vs2010 asp.net4 for us so far... but let me tell you why we took the plunge.

Need to reduce those one-off cookies, session vars or visible query strings?  This is a library that I trust (and I trust very very few these days)

Remaking this site to run on IIS... ELMAH quickly reminded me of that IIS issue:  ignoring custom error handling when spaces or hijack scripts are in the url.

Mostly these come from those cute little korean/slav/russian php scripties, you know the ones, all the variations of: http://[domain]/page%20/index.php?errors=http://www.imajerkwithasmallpenis.tjdhosp.co.kr/1.txt?

IIS and web.config customErrors will take care of most odd url requests.. but embed a space and your customError configuration section won't get called... you need to handle it in the olde Global.asax

The logs show that your pages are redirecting correctly... but a spider type test app shows everything as being status 200 OK... dagnabbit, don't forget that one little property

Now that your Oracle XE server is installed and running, you might like to hit it with a web page or two. You'll need to get a couple of extras for that, the System.Data.Oracle dll that's part of the MS.Net installation but not the Mono core and also a bit of middleware that will route your application calls through that dll to the Oracle server.

Like most things, this is all really easy once you've done it wrong a few times. Lucky for you, I've made all the mistakes already so all you have to do is just follow the bouncing ball.

Get and install the Mono System.Data.OracleClient - Get and install the Oracle Instant Client "middleware"

You don't want to expose a web server to the wild without setting up logging. We all know this. We sometimes forget this. Don't.

Windows developers over the years get cushy with IIS's protection and we take it for granted, but now we're on Apache and going back to our roots of not trusting the core is a good thing.

Our current virtual hosts file is quite a bit different from the Apache default file, if we look to that original we'll see the recommended minimum log lines.

God Forbid

The default behaviour for Apache is to give any user any file that they ask for but you can protect files based on any common or custom file extensions you need.

So far all of our examples have shown a pages-only webapp, no mentions of javascript files, css or images. What all these external resources have in common is that they're typically going to be held in subfolders off of the root.

Related to forbidding folder browsing is forbidding remote access to private files. It's not uncommon to have some quick server-cached lookup data that you want to hold as a file and let the .Net/Mono service work with but not expose to the whole world.

Because the Mono Team knew that most of their new users would be coming over from Windows and usually doing their first tests by dumping some previously written web apps on a Linux box 'just to watch it all fail', they created a one-line compatibility command called Mono IOMAP.

Unfortunately for new users, the setting is not the default (but experienced users would probably not want it bo be). It is turned on at the overall Apache service level by adding the following line to the top of the /etc/apache2/httpd.conf file:

It could be the hugest annoyance when a Microsoft developer tries Mono. Windows at its core is case insensitive. Linux is not.

This useless carryover from the early days of OSes and compilers affects all code that interacts with the file system, and all code done in VisualStudio using the automatic Propercase style that is then XCopied over to a 'nix box. Specifically for ASP.Net applications it is ready to bite you at any line that references a page, image, stylesheet, downloadable or AV streaming file and on and on. With ASP.Net via Mono on a non-Windows server you have to be absolutely case-correct or your users will get 404 errors.

Because no managed web app is 100% managed we have to address this at both the Apache and Mono layers with both configuration settings and ongoing human effort.

Before you go-live with the server, you should handle the default IP Address request case. Disabling the default Apache "It Works" site using "a2dissite default" will do it BUT...

If your network DNS is resolving site urls to the box and they have a value registered that you haven't set up yet then each request will make Apache go through its list of enabled sites and, not finding a match, the last site in its collection will be used.

Sooooo, if you have a porn site first and a Christian site to come later, you may not want to tell your DNS administrator about the Christian site until after you have at least a placeholder site set up for it on the server. We're all usually good about this stuff in our SOX-hampered companies but space out on it when pointing multiple Internet domain names to our homeoffice IPs. Do'h!