Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
We are currently evaluating if we could use Ninject for future projects. One condition is, that the libary should NOT force us to call the Dispose method. So, is it really necessary? Will not calling it result in memory leaks and other ugly stuff?
I don’t think Ninject, being a purely managed solution, would have any problems with memory leaks or other things if you don’t call Dispose(). Especially since you would only be calling the kernel’s Dispose() method as one of the last things you do before terminating an application, so memory would be reclaimed by the GC or the OS’ process isolation anyway.
The reason you would want an IoC container that lets you call Dispose() is that it will call Dispose() on any service providers that are implementing IDisposable. Which is a useful feature, I believe, since service providers might own unmanaged resources or need to wait for asynchronous operations to be completed (or at the very least abort them in an orderly fashion).
I’d go as far and wager that this is the reason behind most IoC containers that implement IDisposable on their kernel/provider/locator class.
Why is having Dispose() on an IoC container a problem for you? So far, I’ve always found an appropriate place to call it, be it in a console application, a XAML-based WPF application or an Xbox game.