Paul Knopf

> If so, you can probably just cast it to a DbConnection (which is what it should have been all along). Why do you say this?

Considering using ```IDbConnection``` would give you the least-common-denominator, supporting *every* implementation (Dapper, ServiceStack.OrmLite, etc), why insist on using ```DbConnection```? What do you *gain*?

Fair enough. > since the concrete classes replaced the interfaces. Can you expand on this?

> is the problem that ServiceStack is creating your DbConnection for you, and you want to preserve that? Exactly. I see now that I can cast a few times to...

Yeah, I like that approach better. Any time I cast interfaces to implementations, I get nervous. The API I'm using (ServiceStack.OrmLite) may choose to internal the implementation, or change it,...

+1

Here is a failing unit test. ``` [TestFixture] public class ContainerTests { [Test] public void Can_store_open_generics_as_singleton() { // arrange var container = new TinyIoCContainer(); // conventions say this will store...

This resolve it. Should I make a pull request? ``` /// /// A factory that lazy instantiates a type and always returns the same instance /// private class SingletonFactory :...

Hmm, sorry, I see another issue here with the same issue: #202 I think it comes down to the number of `:`'s used. Let me try that real quick.

Yup, this works: ``` ::::section-columns :::section-column column 1 ::: :::section-column column 2 ::: :::: ``` Any ideas why that is required? Pandoc seems to handle it (correctly?).