The resolved objects have the same life-time/dispose cycle as their container, that’s unless you manually dispose the transient services in code using using statement or .Dispose() method. In ASP.NET Core you get a scoped container that’s instantiated per request and gets disposed at the end of the request. At this time, scoped and transient dependencies … Read more
Yes, go for it. Although some people think IDisposable is implemented only for unmanaged resources, this is not the case – unmanaged resources just happens to be the biggest win, and most obvious reason to implement it. I think its acquired this idea because people couldn’t think of any other reason to use it. Its … Read more
P.S.: I have posted a new answer (containing a simple set of rules who should call Dispose, and how to design an API that deals with IDisposable objects). While the present answer contains valuable ideas, I have come to believe that its main suggestion often won’t work in practice: Hiding away IDisposable objects in “coarser-grained” … Read more
The general rule of resources is that: He who owns the resource is responsible of disposing of it. This means that if a class owns a resource, it should either dispose of it in the same method that it created it in (in which case the disposable is called an ephemeral disposable), or if that’s … Read more
There’s nothing special about IDisposable here – but there is something special about iterators. Before C# 2, using this duck type on foreach was the only way you could implement a strongly-typed iterator, and also the only way of iterating over value types without boxing. I suspect that if C# and .NET had had generics … Read more
As several others have pointed out in general this is not a problem. The only case it will cause you issues is if you return in the middle of a using statement and additionally return the in using variable. But then again, this would also cause you issues even if you didn’t return and simply … Read more
Unlike most types which implement IDisposable, DataContext doesn’t really need disposing – at least not in most cases. I asked Matt Warren about this design decision, and here was his response: There are a few reasons we implemented IDisposable: If application logic needs to hold onto an entity beyond when the DataContext is expected to … Read more
When you call GetAllAnimals it doesn’t actually execute any code until you enumerate the returned IEnumerable in a foreach loop. The dataContext is being disposed as soon as the wrapper method returns, before you enumerate the IEnumerable. The simplest solution would be to make the wrapper method an iterator as well, like this: public static … Read more
Yes, foreach will call Dispose() on the enumerator if it implements IDisposable.
Yes, Dispose will be called. It’s called as soon as the execution leaves the scope of the using block, regardless of what means it took to leave the block, be it the end of execution of the block, a return statement, or an exception. As @Noldorin correctly points out, using a using block in code … Read more