Before starting this post, I have to say that I am not an huge expert of CastleWindsor & my knowledge on garbage collection and memory management is limited, if you think that I am saying something wrong, please leave a comment or point to an useful link.
Let’s say that you are coding a pipeline component and you want to make it easy to test and isolate the dependency and most of the logic for your pipeline component is handled in an external class….
let’s say that your class was installed as LifestyleTransient
The easiest way to use it in your pipeline component would be using the service locator pattern:
var classInstance = DIContainer.Resolve<IYourInterface>()
but you have to be aware that following this route, nobody will dispose for you the memory…. initially I thought that the GarbageCollector would do the job, but talking with some CastleWindsor expert, he explained me that your DIContainer has a reference to your class and it won’t clean it up when you need memory since it is still referenced by the Container object….
The only solution that I have been suggested is to Release your object explicitally in your pipeline component otherwise you will have a good chance to get a memory leak (obviously it depend on the size in memory that your class take and the traffic of your website…)
public class PipelineSample : HttpRequestProcessor
public override void Process(HttpRequestArgs args)
var classInstance = DIContainer.Resolve<ISomeClass>;
//Do not forget at the end of your method
The issue that I have faced is related to the ServiceLocator pattern and it does not affect the ControllerFactory at all since the controller factory dispose all the dependency passed in the constructor.
Most of developers are using Sitecore & CastleWindsor mostly for histoical reasons, than for a specific reason since from Sitecore 8, DI is completely decoupled from Sitecore and Glass but I would expect that also the other DI would be affected from the same issue if they implement the same concept of lifestyle transient…
An other possible solution to avoid this issue is install the components without using LifestyleTransient but using LifestylePerWebRequest assuming that your code would work reusing the same class multiple time per the request…