ReSharper test runner still going after tests complete

I’ve been writing some tests and I got this message:

[RIDER LOGO] Unit Test Runner

The process ReSharperTestRunner64:26252 has finished running tests assigned to it, but is still running.

Possible reasons are incorrect asynchronous code or lengthy test resource disposal. If test cleanup is expected to be slow, please extend the wait timout in the Unit Testing options page.

It turns out that because I was setting up an IHost as part of my test (via a WebApplicationFactory) that it was what was causing issues. Normally, it would hang around until the application is told to terminate, but nothing in the tests was telling it to terminate.

The culprit was this line of code:

var factory = new WebApplicationFactory<Startup>().WithWebHostBuilder();

The factory is disposable and I wasn’t calling Dispose() explicitly, or implicitly via a using statement.

The fix to this was simply to wrap the returned WebApplicationFactory<T> in a using block and the test running completed in a timely manner at the end of the tests.

using var factory = new WebApplicationFactory<Startup>()

or, if by preference, or using an older version of C#:

using (var factory = new WebApplicationFactory<Startup>().WithWebHostBuilder())
// do stuff with the factory

Although this was running in JetBrains Rider, it uses ReSharper under the hood, so I’m assuming this issue happens with ReSharper running in Visual Studio too.

IDisposable objects with StructureMap and ASP.NET MVC 4

I’ve recently discovered a bit of an issue with running an IoC container with ASP.NET MVC’s IDependencyResolver. If you have a controller that has dependencies on things that implement IDisposable then the dispose method was not being called.

Apparently, if the controller itself is disposable then MVC will clean that up and that can obviously clean up any dependencies that it created and are also disposable. However, if you are injecting the dependency then the controller should not really be disposing of those dependencies because it did not create them as it has no knowledge of the lifecycle of those objects – the owner (the object that created the dependency) is really responsible for disposing of its objects.

So, the responsible party for disposing of the is what ever created it. However, in MVC 4 the Service Locator has no way of disposing downstream objects that get created when instantiating the controller, it only deals with the controller directly, so if a downstream object that the controller depends on needs to be disposed then the IoC container has to manage that. Mike Hadlow has a much better explanation of what is going on here and his dealings with using, specifically, Castle Windsor and the IDepenencyResolver.

Since I’m using StructureMap, it does have a way of helping you clean up.

For example, in the Initialisation expression that the ObjectFactory.Initialize uses I’ve got a repository set up like this:


This creates a new Repository for each request that the MVC application receives. However, this on its own is not enough because it means that while each request gets a new repository, none of the resources of these repository objects are being cleaned up because it never releases them. Eventually those resources will run out, be they database connections, file handles, or what ever the repository needs to use.

You can put in your Global.asax.cs file a method called Application_EndRequest() which is called at the end of each request. Or, if you already have one you can simply add this line of code to it.

protected void Application_EndRequest()