I was recently demoing the project to my partner on the staging site (Azure), and I ran into a troubling error having to do with data connections (that I had not experienced running it locally on IIS yet). I immediately thought that it must be an issue with the SQL connections (SqlDbConnection objects that implement the IDbConnection interface, per Dapper) not being closed and/or disposed of correctly.
I remember encountering the same issue when I was developing this very site that you are reading, and the solution is to use the HttpContext scope within StructureMap when configuring it for the IDbConnection interface.
Here's what I started with:
And here's what I refactored it to:
I just added HttpContextScoped (the default is PerRequest scope, see StructureMap docs on Scoping and Lifecycle Management). I also added the ReleaseAndDisposeAllHttpScopedObjects to Global.asax.cs, so that StructureMap would...release and dispose those objects at the end of each request.
However, when I did that, I was still getting problems. I would get exceptions saying that the SqlConnection ConnectionString was the empty string. Something wasn't right. I did some searching around about the issue in the docs, and couldn't really find what I was looking for. I did come across someone with a similar issue on StackOverflow, also trying to understand HttpContextScoped. The top answer from PHeiberg (not the accepted answer) pointed me the right direction.
I used a lambda expression instead of just passing the SqlConnection directly. So now my SqlDbConnections are scoped to the HttpContext, and will be cleaned up after every request. That should squash the issue I was seeing on the staging stie.
Perfect, just what I was after :)
Glad you found it useful. If you're using a newer version of StructureMap, check out some of the related changes: https://crosscuttingconcerns.azurewebsites.net/StructureMap-3---some-changes-Ive-noticed
Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.