• AspNet Core Nested Applications

    Given any application of a reasonable size, to reason about it and manage complexity one generally applies modular programming along clear and well defined boundaries. Recently I was seeking to do this with AspNet Core where I wanted to compose several independent applications, potentially developed by separate teams, within the one host.

    Nested Apps

    Out-of-the box this is achieved with middleware, however this still means there is a single dependency injection container whose service registration code gets large and leaky. Occasionally there were classes and configurations that clashed. While useful for a lot of scenarios, AspNetCore middleware wasn't giving me the isolation I desired: defined controllers, own static content, auth middleware settings, independent policy definition, focused service registration and more. Basically I want multiple StartUp classes representing the different applications and connect them to a path in a host application.

    Prior to AspNet Core this was easy to achieve with OWIN. Nested applications were just an AppFunc that you build and connected when wiring up an an app.MapPath("path", appFunc). With AspNet.Core we need to take another approach.

    Read more...


  • Commercial Suicide - Integration at the Database Level

    This post was originally authored by Jak Charlton in 2009 and is originally hosted at devlicio.us. That site appears to be inactive and regularly unavailable so, with permission, I'm re-publishing it here as I think it's a timeless piece.

    There are many ways you can commit commercial suicide, but there is possibly no slower and more agonising death than that produced by attempting that great architectural objective, the single authoritative database to which all applications talk.

    The theory is good, if we have a single database then we have all our business information in one place, accessible to all, easy to report against, reduced maintenance costs, consistency across all applications, and a host of other good objectives.

    However all these noble ideals hide a more fundamental problem, that the single database does not solve any of them, and makes most of them into far bigger problems.

    Read more...


  • Capturing Log Output in Tests with XUnit 2

    02 Jun 2015

    xunit 2.x now enables parallel testing by default. According to the docs, using console to output messages is no longer viable:

    When xUnit.net v2 shipped with parallelization turned on by default, this output capture mechanism was no longer appropriate; it is impossible to know which of the many tests that could be running in parallel were responsible for writing to those shared resources.

    The recommend approach is now to take a dependency on ITestOutputHelper on your test class.

    But what if you are using a library with logging support, perhaps a 3rd party one, and you want to capture it's log output that is related to your test?

    Because logging is considered a cross-cutting concern, the typical usage is to declare a logger as a static shared resource in a class:

    public class Foo
    {
        private static readonly ILog s_logger = LogProvider.For<Foo>();
    
        public void Bar(string message)
        {
            s_logger.Info(message);
        }
    }
    

    The issue here is that if this class is used in a concurrent way, it's log output will be interleaved, just in the same way as using console in tests.

    Read more...


  • Stepping down as NEventStore coordinator

    I can't remember exactly when it happend, but for the last few years at least, I have been the core maintainer / coordinator of NEventStore. Built by Jonathan Oliver and just known as EventStore at the time (not related to the other EventStore), it provided me and many people with a really easy way to get up and running with event sourcing. For unknown reasons the core maintainers back then stepped back and since I was heavily invested in it, I offered to take it over.

    Since then it has gone through a rename, 2 major versions and a bunch of minor releases. In that process I learned a lot about running an OSS project and connected with a lot of cool and smart people. This is something that I would highly recommend to any developer looking to get into OSS.

    In the last 12 months or so I haven't been responsive enough to the community, issues, pull-requests, google group etc., and it's time to make a statement. While I'm fairly stretched time wise, the core reason is that as I've as learned to build event sourced systems over the years, NEventStore's current design no longer works for me. While I'm using GetEventStore in some scenarios, I still, and will continue to, have a need for SQL backed event stores. How I'd like to see and interact with such stores is significantly different to how NEventStore currently works. I could mould NEventStore into how I'd like it to be but then the changes would very likely alienate people and break their stuff. Thus it's best that I head off in my own direction.

    If you are vested into NEventStore and would like to take over and run a popular OSS project (nearly 800 stars and 250 forks on github, and 10's of thousands of nuget downloads), please reach out to me :)

    Read more...


  • Testing OWIN applications with HttpClient and OwinHttpMessageHandler

    Let's take the simplest, littlest, lowest level OWIN app:

    Func<IDictionary<string, object>, Task> appFunc = env =>
    {
        env["owin.ResponseStatusCode"] = 200;
        env["owin.ResponseReasonPhrase"] = "OK";
        return Task.FromResult(0);
    }
    

    (In reality you'll probably use Microsoft.Owin or LibOwin to get nice typed wrapper around the OWIN environment dictionary instead of using keys like this.)

    How do you test this?

    Well you could create your own environment dictionary, invoke appFunc directly and the assert the dictionary.

    [Fact]
    public async Task Should_get_OK()
    {
        var env = new Dictionary<string, object>()
    
        await appFunc(env);
    
        env["owin.ResponseStatusCode"].Should.Be(200);
        env["owin.ResponseReasonPhrase"].Should.Be(OK);
    }
    

    While this would work it, it's not particularly pretty and it'll get messy fairly quickly as you may need to assert cookies, dealing with chunked responses, doing multiple requests (e.g. a login post-redirect-get), etc.

    Wouldn't it be nicer to use HttpClient and leverage it's richer API? It would also better represent an actual real-world client. Something like this is desirable:

    [Fact]
    public async Task Should_get_OK()
    {
        using(var client = new HttpClient())
        {
            var response = await client.GetAsync("http://example.com");
    
            response.Status.Should().Be(HttpStatusCode.OK)
        }
    }
    

    Read more...