Thinking in a document centric world with RavenDB @ ALT.NET

Last night (25th Feb 2014), I presented on RavenDB at ALT.NET Melbourne.

I got some great feedback from the audience and was happy to share my experience so far with RavenDB. If you were there / watch the recording and have some suggestions good or bad would love to hear them so I can improve.

Here’s the ALT.NET recording with slides, plus me up at the projector screen.

If you just want the slides and audio then here’s an alternate recording.

I’ve also put the slides up on slide share.

HTTP Error 500.19 – Internal Server Error with ASP.NET web on Windows 8 and IIS 8

I’m blogging this (again*) so next time I do a search I find my own post, it may also help you. I manage a few development VMs which I swear I have setup in the past correctly, but every so often I find one that’s got the following problem.

*Again: it’s in an older post in the trouble shooting part, but this time, the error is the title of the post to help indexing, as when I searched this time around, that post did not come up.

Scenario / Error

Windows 8 + IIS launching your ASP.NET web app, you get the following IIS error:

HTTP Error 500.19 – Internal Server Error
The requested page cannot be accessed because the related configuration data for the page is invalid.

Error Code 0x80070021
Config Error This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false”.

Note the ‘locked at a parent level’, in the config error.


Turn on the Application Development Features. If they’re already on, then you have a different problem, there’s a few questions about ASP.NET IIS and 500.19 on Stack Overflow.

Enable IIS 8 App Dev Features

Hope this helps.

F# Newbie

On the 5th of June* at work we decided to give F# a go and by ‘go’ I/we mean really use it in the most important parts of our application. Some of the team has had greater exposure to functional languages like Haskell and Scala, they are the ones being our champions and guiding the rest.

*I know the exact date because it is marked by a small commit of a blank F# project added to the solution I went back and checked.

This was not a snap or rushed decission but one with a fair few chats over code examples and a proof of concept.

If I have to boil down the decission to go ahead with F# at this early stage it is:

  • Record Types
  • Patern Matching
  • Immutability

These language features combined with team motivation to be working with something new and interesting “sold” the rest of us who haven’t didn’t have the exposure yet.

At this point I want to confess that it’s a strange feeling to be working with F# code and not having the same level of confidence to make changes and jump in and write like I would with my near decade of experience in C#. Many would argue that that’s actually quite a good thing, and I’m starting to agree – for one thing it means I’m thinking longer about the code.

It’s very easy to just write some procedural logic, call some methods, change variables, and just keep writing until it works and think about tidying it up after the fact, or worse leaving a “//TODO: clean this up” comment for a future self or peer to rage over.

Take the preceding paragraphs and the title of the blog post as my disclaimer that this is all new to me but here goes… My take on the concepts I understand and apprecaite about F# so far are simple and based on and how it’s helping me and the team so far to write code more easily.

Record Types

Concise / less code

In our CQRS style application we have lots of little commands (that’s what the C stands for), and lots of events so being able to very succinctly create these is a huge win.

More info here.

Pattern Matching

Concise / less code

In particular there must always be some branch that matches and if there isn’t you get a compile time error.

incomplete pattern match

Go here to learn all about it.



Of the 3 things I this is the most fundamental F# concept that I can appreciate so far, at a mimimum it’s about avoiding side effects in your code, and makes you think about transforming data as it flows through your application. In our CQRS world this is a great match, a command gets populated, it shouldn’t change. An event gets produced, that’s even more definate it happened – here’s what happend it doesn’t change.

Just like all the links about F# a great source is

Did you notice the trend for each of the 3 items I chose to cover, that’s right it’s about being concise. The immutabilty may not always be less code but you absoultely do get conciseness. If you take 1 thing away from this is that how could less code possibly be bad, less to write, less to mainting, win, win.

That’s it for now, we haven’t had to give up and re-write all this code in C#.

Moving from WebAPI to ServiceStack

Having used WebAPI in conjunction with a hybrid WebAPI and ASP.NET MVC app quite recently, it does a good job, but once you start to get deeper in a more complex application some weaknesses start to show. A trivial example is mapping exceptions to HttpStatus codes, this is something you get easily with ServiceStack.

The WebAPI controllers looked like this, with a route prefix at the top, and then the specific part with

    public class ProductController : ApiController
        public Product Get(ProductId id)
        { /* ... */ }
        public void Post(CreateProductCommand cmd)
        { /* ... */ }
    // New style as route decorating an F# record
    [<Route("/product/create", "POST")>]
    type CreateProductCommand =
        ProductId: ProductId
        Name: string

Yes F#, checkout out my post on initial learnings with F#. There’s something interesting about our route decorations on that record type, I’ll try to get around to writing about it. But for context this time round it’s

Issues with WebAPI

Our primary issue with WebAPI was that its route matching was limited.

As a result, it frequently did not match routes in an expected way. This often resulted in a great deal of time lost to fiddling about and trying to come up with a pattern that would satisfy what Web API wanted, often at the expense of our public API design. Also, we wanted to take advantage of routing features that already exist in ServiceStack, but are still only planned in the future for WebAPI.

Finally, as our product’s hosting needs grow, we may like to take advantage of cheaper Amazon machine images and run our services on Linux; ServiceStack is a first-class Mono citizen.


We’re quite happy so far having run it for ages.

Months later in production still very happy.

Cross subdomain ASP.NET Forms Authentication for local developement

I’ve had this issue twice now, and both times when I did my search I would end up this popular Stack Overflow question but adding an answer to a popular question that doesn’t directly* answer the question will get the attention of down vote police.

*For some values of direct.

So I’ll just have to blog it here, and maybe the comment will help someone out who is likely to end up on that question, at least until the comment is flagged as unconstructive or offensive because “somewhat related” isn’t in the spirit of StackOverflow.

So with the grievance aired.


To be able to have subdomain1.machine-name and subdomain2.machine-name share a cookie locally via forms authentication.


To go about achieving the saving of an authentication cookie valid across multiple domains locally under IIS.


The most important thing here is to ensure that your local domain has at least ‘.’ in it. I often try to just have it be the machine name, this does not work, so I select something like the .app suffix.

Authentication configuration section in web.config:

   <authentication mode="Forms">
      <forms loginUrl="~/login" timeout="2880" domain="" />

IIS Setup

Will look like this:

iis settings


hosts file


There we go, with this set up you can go to red. and blue. and have it share the authentication cookie to be logged into your app across sub domains locally.

dashbaord blue


I also ran into some extra issues on Windows 8 similar to this StackOverflow question.

Exception from IIS:

HTTP Error 500.19 – Internal Server Error

The requested page cannon be access because the related configuration data for this page is invalid.

This configuration section cannot be used at this path. This happens when the section is locked at a parent level. Locking is either by default (overrideModeDefault=”Deny”), or set explicitly by a location tag with overrideMode=”Deny” or the legacy allowOverride=”false.

To solve this you need to probably enable some Windows Features related to Security and .NET.

features toggle pointing

Tracking application errors with

A nice coincidence a few weeks was the news of Raygun going in to public beta crossing my radar.

At the time we were fine tuning some things in an application that was in a private beta, we had put a little effort in to ensure that we would get reliable results about errors that happened to the users, but at that point we were just storing the details in a database table.


We were capturing 3 levels of errors in the application.
– Client-side (JavaScript)
– Web Tier (ASP.NET MVC / WebApi)
– Back-end (Topshelf hosted services)

Any client side error would be captured, and sent to the Web Tier, Web Tier forwards that and it’s own errors on to the back end where they would be persisted with low overhead. In a previous post I have covered this approach.

But to get from entries stored in a database to something actually useful to correctly monitory and to start a resolution process is quite a bit of work.

From our own application structure; we can easily query that table, and just as easily send emails to the dev team when they occur. But this is still short of a robust solution, so a quick glance at the Raygun features and there was very good reason to give it a go.

What it took for us to set up Raygun

A quick look at the provided setup instructions and their github sample, it looked very easy.

With our particular application structure the global Application_Error method and the sample usage of Server.GetLastError() didn’t fit well. The clearest example is the arrival of data from client side, which isn’t a .NET exception, so simply issuing the RaygunClient().Send(exception); call doesn’t work. In this scenario we basically recreate an exception that represents the issue in the web tier, then have that sent to Raygun.

For errors that originate in our controllers (regular and WebApi) which extend a common base class, we make use of the HandleError attribute so we can execute a method to do some extra work, the code looks like:

public abstract class BaseController
    protected override void OnException(ExceptionContext filterContext)
        //our other logic, some to deal with 500s, some to show 404s

        //make the call here to raygun if it was anything but a 404 that brought us here.
        new RaygunClient().SendInBackground(filterContext.Exception);

In the scenarios where we actually do have the exception, then it’s great and it “just works”, and we send it off asynchronously, in the catch block by calling a wrapping function like this:

public static void LogWithRaygun(Exception ex)
    new RaygunClient().SendInBackground(ex);


So Raygun really helped us avoid using a weakly hand-rolled half-way solution for tracking errors, now with nice email notifications that look like this, and link into the Raygun detailed information view.

It’s lacking a few nice to have features, but that’s more than acceptable for version 1 of the application, and from what we’ve been told our suggestions are already on track for a future release. One particular one that would benefit lots of people would be to allow an association of errors to be mapped by the user. An example is, 2 seemingly different errors get logged but in actual fact are the same cause, this way the reporting and similarity tracking can continue to group the 2 variations under the one umbrella.

raygun email example

Along with the dashboard summary.

Part of the Raygun  Dashboard

It’s one less thing we need to worry about. Just an FYI we didn’t stop saving records into our own database table, we’re just unlikely to have to go looking in there very much, if ever.

When you need to generate and send templated emails, consider mailzor

Mailzor is a basic utility library to help generate and send emails using the Razor view engine to populate email templates, designed to be quickly pluggable into your .NET app.

In our applications we send out HTML formatted emails, and seed them with a variety of data. I thought it would be easy to write them as razor files (cshtml) and then use the razor engine to generate them and send.

It’s up on NuGet and with the release of v1.0.0.11, it’s more stable.

For the most up to date info follow along with the usage sections of the file on the github repository.

How it works

I thought I would share some background about the development of it, and hiccups along the way. The original set of code came from Kazi Manzur Rashid, which solved the problem of making use of System.Web.RazorTemplateEngine, which I extended (with permission) to be usable as an injectable dependency and via NuGet.

The core elements are, the creation and management of the SMTP client, the building up of the MailMessage. Then all the compilation related work to get the RazorTemplateEngine up and running.

The RazorTemplateEngine logic boils down to taking the razor file stored on disk and using CSharpCodeProvider.CompileAssemblyFromDom. So if you’re curious about this code in particular dig into EmailTemplateEngine.cs in the project files.

Prior to version .10 where I went down the path of using ilmerge to solve conflicts of version mismatch with System.Web.Razor.

It seems easy seeing how I took an existing chunk of operational code and extended, and it only seems easy when it is working, but when it doesn’t work and you’ve got strange compilation errors, debugging this mechanism is not the greatest. I found myself hunting for temporary files and trying to have other compiler flags to output more information.

In the early versions it was heavily the case of “works on my machine”, but now its fine and seems to be feature complete…