As described in this article.


you can use pipeline "ref" and "factory" attributes, to use dependency injection on a pipeline.

There are newer ways of doing this since sitecore 8.2 (Infact 8.2 update 2 didn't work with this setup, and we had to wait for 8.2 update 3+) As we use Castle, we can't use the Dependency Resolver, as that doesn't call release and cause memory leaks. So utilising this older way of doing dependency injection, which does allow us to call release. (We also are using ControllerFactory for the same reason)

We've just started at looking at how much work to upgrade to Sitecore 9.

ISetting and IFactory have made Obsolete(Infact whole Sitecore.Abstraction.dll removed and moved to Sitecore.kernel.dll)

> Obsolete("Use Sitecore.Kernel!Sitecore.Abstractions.BaseCorePipelineManager instead.")] 
> public interface ICorePipeline
> [Obsolete("Use Sitecore.Kernel!Sitecore.Abstractions.BaseFactory instead.")] 
> public interface IFactory
> [Obsolete("Use Sitecore.Kernel!Sitecore.Abstractions.BaseRuleFactory instead.")] 
> public interface IRuleFactory

And instead of the interface has been replaced with abstract class.

Primary Question - Sitecore support have confirmed this works

Are these hooks still available in sitecore 9 to use "ref" and "factory" to do dependency injection in Sitecore 9? And do they work?

If so how can our Factory (which uses Castle) implement IFactory without getting a obsolete build warning, or how would we use the replacement base factory in a "ref" and "factory" scenario? Just realised that this is using the Sitecore.Reflection.IFactory


Secondary Question

The "ISetting" & "ICorePipeline" & "IFactory" we were using in our Dependency Injection setup, how could we use the replacement abstract classes to achieve the old behaviour in our DI setup without getting the obsolete build warnings?

As we'll need to move away from this when this obsolete code is removed in a future version.

  • And you've tried using the resolve="true" attribute on processors? kamsar.net/index.php/2016/08/…
    – jammykam
    Commented Mar 5, 2018 at 16:11
  • We can't use that with Castle :(
    – Ian
    Commented Mar 5, 2018 at 16:25

2 Answers 2


Primary Question

Sitecore support have come back, Ref & Factory are still available in sitecore 9.

The Sitecore.Reflection.IFactory has not been marked as obsolete, it's the Sitecore.Abstractions.IFactory that has been marked as obsolete.

Secondary Question

I've had a look at /sitecore/admin/ShowServicesConfig.aspx

and can see for BaseFactory the implementation is

Sitecore.Abstractions.BaseFactory, Sitecore.Kernel 
Sitecore.Configuration.DefaultFactory, Sitecore.Kernel

for BaseRuleFactory the implementation is

Sitecore.Abstractions.BaseRuleFactory, Sitecore.Kernel 
Sitecore.Rules.DefaultRuleFactory, Sitecore.Kernel    

for BaseCorePipelineManager the implementation is

Sitecore.Abstractions.BaseCorePipelineManager, Sitecore.Kernel 
Sitecore.Pipelines.DefaultCorePipelineManager, Sitecore.Kernel    

for BaseSettings the implementation is

Sitecore.Abstractions.BaseSettings, Sitecore.Kernel
Sitecore.Configuration.DefaultSettings, Sitecore.Kernel

We'll try updating our code to reference these new base classes, and register these default instances in our IoC container.

Not sure why the interfaces have been removed, and replaced with abstract classes.

Will mark this as closed once verified resolves our issues.


I am sure you have solved this by now but wanted to post what I ended up having to do to get the use of a container adaptor factory working for a processor in the getLayoutServiceContext pipeline for JSS. Rather than the ref and factory on the processor directly the processor ref pointed to an element in types node of the layoutService group.

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
      <group groupName="layoutService">
              ref="SitecoreJss.Examples.ExampleContextExtension, SitecoreJss.Examples" 
                <AllowedConfigurations hint="list">
                    <!-- Unless you change the Layout Service config used by your JSS app, this should always be present. -->
                <Applications hint="list">
                    <!-- Restrict the JSS apps for which this processor will execute. -->
                <Routes hint="list">
                    <!-- Restrict the route items for which this processor will execute. IDs, item paths, and wildcard item paths are allowed. -->
            <processor ref="ExampleContextExtension"/>

I have blogged on this also if you or anyone else is interested in more detail.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.