As anyone I work with can attest, I a have been prattling on about strong typing everything for quite a while. One of the places I feel people don’t utilise strong typing enough is in application configuration. This manifests in a number of problems in a codebase. The Problems The first problem is when nothing at all is done about it, and you end up with code spattered with this:...

I like to make my development life as easy as possible - and removing small irritations is a great way of doing this. Having used Shouldly in anger for a long time, I have to say I feel a little hamstrung when going back to just using NUnit’s assertions. I have been known on a couple of projects which use only NUnit assertions, when trying to solve a test failure with array differences, to install Shouldly, fix the test, then remove Shouldly again!...

My new place of work has a lot of nuget packages, and I wanted to understand the dependencies between them. To do this I wrote a simple shell script to find all the packages.config files on my machine, and output all the relationships in a way which I could view them. The format for viewing I use for this is Graphviz’s dot language, and the resulting output can be pasted into WebGraphviz to view....

One of the downsides to microservices I have found is that I end up repeating the same blocks of code over and over for each service. Not only that, but the project setup is repetitive, as all the services use the Single Project Service and Console method. What do we do in every service? Initialise Serilog. Add a Serilog sink to ElasticSearch for Kibana (but only in non-local config.) Hook/Unhook the AppDomain....

This is a follow up post after seeing Michal Franc’s NDC talk on migrating from Monolithic architectures. One point raised was that Database Integration points are a terrible idea - and I wholeheartedly agree. However, there can be a number of situations where a Database Integration is the best or only way to achieve the end goal. This can be either technical; say a tool does not support API querying (looking at you SSRS), or cultural; the other team either don’t have the willingness, time, or power to learn how to query an API....

This article is some extra thoughts I had on api structure after reading Derek Comartin. Asides from the benefits that Derek mentions (no fat repositories, thin controllers), there are a number of other advantages that this style of architecture brings. Ease of Testing By using Command and Queries, you end up with some very useful seams for writing tests. For controllers With controllers, you typically use Dependency injection to provide an instance of IMediator:...

Quite a number of my projects involve talking to RabbitMQ, and to help check things work as expected, I often have a number of integration tests which talk to a local RabbitMQ instance. While this is fine for tests being run locally, it does cause problems with the build servers - we don’t want to install RabbitMQ on there, and we don’t typically want the build to be dependent on RabbitMQ....

When changing a project’s build script over to Gulpjs, I ran into a problem with one step - creating an AssemblyInfo.cs file. My projects have their version number in the package.json file, and I read that at compile time, pull in some information from the build server, and write that to an AssemblyVersion.cs file. This file is not tracked by git, and I don’t want it showing up as a modification if you run the build script locally....

Recently I have been writing a WebApi project which needs to accept plaintext via the body of a PUT request, and did the logical thing of using the FromBodyAttribute public HttpStatusCode PutKv([FromBody]string content, string keyGreedy) { return HttpStatusCode.OK; } Which didn’t work, with the useful error message of “Unsupported media type.” It turns out that to bind a value type with the FromBody attribute, you have to prefix the body of your request with an =....

Last time we went through creating a Dockerfile for a microservice, with the service being compiled on creation of the container image, using xbuild. However we might not want to compile the application to create the container image, and use an existing version (e.g. one created by a build server.) Our original Dockerfile was this: FROM mono:3.10-onbuild RUN apt-get update && apt-get install mono-4.0-service -y CMD [ "mono-service", "./MicroServiceDemo.exe", "--no-daemon" ] EXPOSE 12345 We only need to make a few modifications to use a pre-compiled application:...