Users, when presented with issues in software (Error messages, unexpected behavior, etc), tend to try to explain things with what limited knowledge they have, and the lions share of users don’t understand the inner workings of software. Commonly this is know as Abductive reasoning, the processes of forming a conclusion based on the simplest possible explanation without much investigation.

Generally I find users draw conclusions in this manner from their past negative experience with your or other applications.

The first example I want to mention is relating users picking up on similar repeated error messages.

I used to expose the Message property of the Exception object in the error message to the users, in a hope to help in trouble shooting. This ended up causing a serious issues with the users reasoning.

As you may know one of the most common programming mistake in .NET is a “Object Reference not set to an instance of an object”, or null reference error. I once had a user say to me:

It’s been 6 months and we are still getting the same Object Reference Error coming back again, and again, when are you going to fix this Object reference error?

It was of course not the same error, when applying new development work I had made this common mistake and introduced a null reference error a few times. The user though saw the same error, even though it was in different section of the application, and assumed the same problem, most annoyed because it was the same issue he had already paid me 3 times to fix.

Similar unexpected behavior is another one.

I once had a web forms application where I didn’t take much care on the assignment of the default button in the panels, so the enter key had quite unpredictable behavior on some pages when used from textboxes, but it wasn’t until we had a user that didn’t like her mouse that we really started picking up on it.

At first we fixed a couple of pages, then she found more and more, after 3-4 reports of the issues (each on different pages) we realized it was wide spread, bit the bullet, and audited the whole application. Instead of fixing on a per report basis.

But this was enough, the user was poisoned, every time we spoke to her about issue she had she was sure it was “another problem with pressing the enter key”, 6 months later, she was still telling us “I think its another issues with pressing the enter key”.

This behavior of the user is unavoidable, you can’t change human behavior, but you can mitigate the behavior.

Firstly your Error Messages.

If you know what the error is, i.e. its a “handled error”, like your database server is offline/timing out. Then customize all your error messages in good English

A good error message should do two things

1. Tell the user whats wrong
2. Suggest what the user can do next

For example

If the exception you are handling is “SQLException: Timeout Exception”

The database is currently not responding, it maybe temporarily offline or there may be a larger issue. Please try again shortly and contact support if the problem persists.

Next if you have a global error handler like me, or are handling generic exceptions that you might not know what the error is, then be ambiguous and keep your user in the dark, don’t assume they can help you (They are not your friend 🙂 ).

A good error message in this situation is “Unknown Error”, tell the user you don’t know what it is, because you don’t or you would be handling it.

Unknown Error: Please contact support and quote them this number (44FHGI2)

How do you know what it is? Use a correlation ID, SharePoint is an example of this, but not a good one. In SharePoint when you get an error they give you an ID that you can pass on to the support team to lookup the logs, why share point is a bad example is that they use a GUID, have you every asked a user to read you a GUID over the phone?

If you ever have a reference number this long that people maybe reading or typing out make sure its got a check digit in it, and a damn good reason for it being so long.

If you don’t have some sort of sequence you can grab a number from, in your logging system or storage, then generating a fairly unique alpha-numeric code isn’t overly hard, lots of libraries out there. You should also feed your correlation Id into all logs form a users session if you can, not just the error.

Secondly Good Habits.

If someone picks up a mistake you’ve made (like my enter key example above) take some time to think, “How much of an issues is this going to be with the rest of my app?”, don’t let it get out of control, if you find some “bad practice” or even just “lazzyness”, take your time to check it out, Ctrl+Shitf+F is your friend in this circumstance. you can usually get a good indication from a few smart searches how wide spread an issue may or may not be.

Lastly, take some pride in your work.

A job finished isn’t always a job well done. I recommend giving yourself as much “click around time” as you can after your done (also know as exploratory testing if you need a fancy word to justify it to your boss), just clicking around and using it as much as you can, on all sorts of areas, don’t forget tabbing, enter keys, and the usual alternate methods of navigating around.

We’ve always moved towards a SOA, so most of our business logic is in the web service layer, primarily WCF traditionally, but moving towards REST these days. So a lot of our windows services end up as simply a timer that polls a web method, or a timer that pools a web method to then tell it what methods to poll.

Disclaimer: if anyone is saying right now “why are you polling, and not using a Service Bus?”, its mostly to do with 3rd party integration or legacy systems when we need to poll.

In the past we have never contemplated putting something like this into a web app due to IIS limitations around “keep alive” of the app domain.

With Application Initialization as of IIS 8 (and supported in 7.5 with a plugin) we have started to do this. So instead of having a dependence on a windows service we are just dropping timers into the start up of the web app. This reduces the amount of projects we have to deploy/maintain/monitor.

There is a few dependencies on this though beyond just the tag in the web config that need to be set to make an App Domain “immortal”, as I’ve been putting it.

First the tag in your web config

 <applicationInitialization doAppInitAfterRestart="true">
 <add initializationPage="/myService.svc" />
</applicationInitialization>

I usually just throw it at the based svc file, but anything that hits something that executes .NET code is fine, then you need to make sure you have the doAppInitAfterRestart set “true”, in case someone kills the worker process or something odd like that.

Note though that relative paths (using ~) are not supported, so it you have something in a sub app you are going to have to code this path in.

Next is your App Pool Settings, you need to set the following values:

• idleTimeout to 0
• recyclingPeriodicrestart to 0
• startMode to AlwaysRunning

Then you also need to set the following values in your Web Site settings as well

• preloadEnabled to “true”
• serviceAutoStartEnabled to “true”

I use Step Templates in Octopus deploy to check for these values and Update them if note set:

Below is an example of the powershell i use in the AppPool update script

Import-Module WebAdministration
$enable32BitAppOnWin64Val=[System.Convert]::ToBoolean($enable32BitAppOnWin64)
$idleTimeoutVal= [TimeSpan]::FromMinutes($idleTimeout)
$recyclingPeriodicrestartVal= [TimeSpan]::FromMinutes($recyclingPeriodicrestart)

Write-Host "Checking $AppPoolName processModel.idleTimeout is $idleTimeoutVal"
if((Get-ItemProperty "IIS:\AppPools\$AppPoolName").processModel.idleTimeout -ne $idleTimeoutVal)
{
$delPool = Get-Item "IIS:\AppPools\$AppPoolName";
$delPool.processModel.idleTimeout=$idleTimeoutVal;
$delPool | Set-Item
Write-Host "Setting $AppPoolName processModel.idleTimeout to $idleTimeoutVal"
}
else
{
Write-Host "$AppPoolName processModel.idleTimeout is $idleTimeoutVal already"
}

Write-Host "Checking $AppPoolName recycling.periodicrestart.time is $recyclingPeriodicrestartVal"
if((Get-ItemProperty "IIS:\AppPools\$AppPoolName").recycling.periodicrestart.time -ne $recyclingPeriodicrestartVal)
{
$delPool = Get-Item "IIS:\AppPools\$AppPoolName";
$delPool.recycling.periodicrestart.time=$recyclingPeriodicrestartVal;
$delPool | Set-Item
Write-Host "Setting $AppPoolName recycling.periodicrestart.time to $recyclingPeriodicrestartVal"
}
else
{
Write-Host "$AppPoolName recycling.periodicrestart.time is $recyclingPeriodicrestartVal already"
}

Write-Host "Checking $AppPoolName enable32BitAppOnWin64 is $enable32BitAppOnWin64Val"
if((Get-ItemProperty "IIS:\AppPools\$AppPoolName").enable32BitAppOnWin64 -ne $enable32BitAppOnWin64Val)
{
$delPool = Get-Item "IIS:\AppPools\$AppPoolName";
$delPool.enable32BitAppOnWin64=$enable32BitAppOnWin64Val;
$delPool | Set-Item
Write-Host "Setting $AppPoolName enable32BitAppOnWin64 to $enable32BitAppOnWin64Val"
}
else
{
Write-Host "$AppPoolName enable32BitAppOnWin64 is $enable32BitAppOnWin64Val already"
}

Write-Host "Checking $AppPoolName startMode is $startMode"
if((Get-ItemProperty "IIS:\AppPools\$AppPoolName").startMode -ne $startMode)
{
$delPool = Get-Item "IIS:\AppPools\$AppPoolName";
$delPool.startMode=$startMode;
$delPool | Set-Item
Write-Host "Setting $AppPoolName startMode to $startMode"
}
else
{
Write-Host "$AppPoolName startMode is $startMode already"
}

And i use a similar script for the Web Site update, pretty basic stuff.

What about the App Domain? the above will secure the App Pool but not the App Domain, a common cause of app domain restart is a deploy via octopus, when it changes the IIS path it will restart the App Domain of the site. to handle this you need to add a snippet like the below to you Application end event in Global asax

protected void Application_End()
{
var client = new WebClient();
var hostName = Dns.GetHostName();
var url = "http://" + hostName + "/service.svc";
client.DownloadString(url);
}

Once these are all setup you couldn’t kill that App Domain with a crowbar. Even end tasking it from Task Manager it will restart.

So you are safe to run timers and any other services you like in it, just like you would in a windows service.