Took me a while to solve this, so I hope it will help some other sorry arse one day.

Scenario

Wanting to render an error page programmatically in my web app (say a fancy 404 page that can’t be served as a static content, as it might contain the current user’s name, etc.)

I catch the error in the app (Monorail, so I use a Rescue, but do whatever feels good), render the markup, and set the ResponseCode to 401.

* Same trouble will occur with any 40x/50x response’ status code

Problem

IIS will render it’s own static 401 ( or any other 40x/50x ) page

I did check that

customErrors section is set to off, as it used to work in IIS6 just fine

What I missed out

IIS7 introduced the httpErrors section (under system.webServer of course), which is used to tell it what to do with custom errors.

The sub-key I was looking for was <errorMode> with the value set to Detailed.

So, adding

<system.webserver>
   ...
   <httperrors errormode="Detailed" />
   ...
</system.webserver>

made my problem go away.

Also notice that

you might need to allow setting that value in your web.config, by going to c:\Windows\System32\inetsrv\config\applicationHost.config, allocating the declaration of the section named “httpErrors” and set its overrideModeDefault attribute to "Allow". 

I’ve just found out that my I’m being *quoted in a book !

the book is Testing ASP.NET Web Applications (Wrox Programmer to Programmer) from Ben Hall, a great guy I know from the first UK ALT.NET conf, and another guy, who happens to blog quite rarely, but I do like his

So You Think You’re A Web Developer series. Plus anyone investing time in Web apps testing is a worthy man, not to mention a guy that invests time in educating people into testing their web apps.

* Actually, it’s not anything smart that I’ve been saying, but rather my simple IoC implementation, which I originally created for a tiny project that couldn’t have had *any 3rd party dependency (including Windsor), and is now being used as a manner of teaching what an IoC is and how it can help you.  neat, and thx for the credit.

When using Windsor’s logging facility, you’d usually take a dependency of an ILogger in your component, and have Windsor create the logger instance. The logger’s name will be of your component’s full type name.

e.g. for the following component:

namespace My.Application
{
	public class UsingLogIntegration
	{
		readonly ILogger logger;
		public UsingLogIntegration(ILogger logger)
		{
			this.logger = logger;
		}
	}
}

The logger's name will be My.Application.UsingLogIntegration

At times, you would need to get a logger in a different way, either because you’d want a special name, or you will be in a location where you cannot have Windsor resolve that for you as a dependency (say within an ASP.NET’s Global.asax class, which gets instantiated by ASP.NET, not by Windsor).

The naive approach would be to ask the container for an ILogger, however if you’d try this, you’ll discover that Container.Resolve<ILogger>() will not fit your needs. So what will you do?

Well, the facility also sets an ILoggerFactory, which is in charge of creating loggers. So, do that instead:

var loggerTypeOrName = GetTheTypeForTheLoggerOrAStringIfYouPrefer();
var logger = Container.Resolve().Create(loggerTypeOrName);

ILoggerFactory.Create() can live with a type (will use the full type name as name) or with a string.

Anyone who have ever seen something like that might relate to this post:

Breaking the CI is not nice, however it does happen at times. When it happen, someone (myself this time) is appointed responsible, and will fix the build asap.

However, sometimes people do break the CI *and then go home without fixing it*

There are a few ways to deal with that. Usually you’d call the person who did the commit that made the build fail, and will consult with him about the best way to fix it quickly until he gets back. But sometimes it would prove complex to fix for someone that try to come in without having good knowledge on the full context.

So would you keep the CI red? that’s really bad, as you won’t get good feedback if someone else commits bad work, as it won’t *turn* to red, it would rather simply *stay* red.

At these times you’d simply wish that the person who broke the build wouldn’t have committed his change in the first place.

STOP WHISHING

That’s what source control is for.

Just fire up your Subversion Log, gitk, whatever (I guess that even TFS has that ability ;) ), figure out the offending commit id, and revert these changes.

Then you get your CI in a good shape again, and you are free to break it in the regular day-to-day manner.

The CI breaker will then come back in tomorrow and will examine his change, then re-apply it correctly.

How lame can you get?

It is even misspelled.

The funniest saddest thing is the source of this page:

<script language="JavaScript"> 
if (document.all) {
 document.writeln(...);}
else {
 document.writeln("<p><font color=\"#999999\"><b>Error ! The current browser is either too old or too modern (usind DOM document structure).</b></font></p>");}
</script> 

So many bad practices in a such a small snippet. And the stuff in the (…) part was too painful to paste.