ServiceContainer, IoC, and disposable objects-Collection of common programming errors

I have a question, and I’m going to tag this subjective since that’s what I think it evolves into, more of a discussion. I’m hoping for some good ideas or some thought-provokers. I apologize for the long-winded question but you need to know the context.

The question is basically:

• How do you deal with concrete types in relation to IoC containers? Specifically, who is responsible for disposing them, if they require disposal, and how does that knowledge get propagated out to the calling code?

Do you require them to be IDisposable? If not, is that code future-proof, or is the rule that you cannot use disposable objects? If you enforce IDisposable-requirements on interfaces and concrete types to be future-proof, whose responsibility is objects injected as part of constructor calls?

Edit: I accepted the answer by @Chris Ballard since it’s the closest one to the approach we ended up with.

Basically, we always return a type that looks like this:

public interface IService : IDisposable
    where T: class
{
    T Instance { get; }
    Boolean Success { get; }
    String FailureMessage { get; } // in case Success=false
}

We then return an object implementing this interface back from both .Resolve and .TryResolve, so that what we get in the calling code is always the same type.

Now, the object implementing this interface, IService is IDisposable, and should always be disposed of. It’s not up to the programmer that resolves a service to decide whether the IService object should be disposed or not.

However, and this is the crucial part, whether the service instance should be disposed or not, that knowledge is baked into the object implementing IService, so if it’s a factory-scoped service (ie. each call to Resolve ends up with a new service instance), then the service instance will be disposed when the IService object is disposed.

This also made it possible to support other special scopes, like pooling. We can now say that we want minimum 2 service instances, maximum 15, and typically 5, which means that each call to .Resolve will either retrieve a service instance from a pool of available objects, or construct a new one. And then, when the IService object that holds the pooled service is disposed of, the service instance is released back into its pool.

Sure, this made all code look like this:

using (var service = ServiceContainer.Global.Resolve())
{
    service.Instance.DoSomething();
}

but it’s a clean approach, and it has the same syntax regardless of the type of service or concrete object in use, so we chose that as an acceptable solution.

Original question follows, for posterity

Long-winded question comes here:

We have a IoC container that we use, and recently we discovered what amounts to a problem.

In non-IoC code, when we wanted to use, say, a file, we used a class like this:

using (Stream stream = new FileStream(...))
{
    ...
}

There was no question as to whether this class was something that held a limited resource or not, since we knew that files had to be closed, and the class itself implemented IDisposable. The rule is simply that every class we construct an object of, that implements IDisposable, has to be disposed of. No questions asked. It’s not up to the user of this class to decide if calling Dispose is optional or not.

Ok, so on to the first step towards the IoC container. Let’s assume we don’t want the code to talk directly to the file, but instead go through one lay