Getting Dependency error when using RegisterPerWebrequest

May 26, 2011 at 10:04 PM

Excellent work this project, I was using Ninject but reverted to your (more down to earth) Injector because I was having problems and felt lost. By the way the performance is excellent too!

Now when converting everything from Ninject to yours I am also using your RegisterPerWebrequest extension method. The problem is it is giving the following error upon validation:

The configuration is invalid. The type WUR.Nemabase.Services.Business.RavenService`1[WUR.Nemabase.Business.ApplicationContent] is directly or indirectly depending on itself

When I change to Singleton mode, no error at all.

Here is some strippped code (stripped for your convenience):

1. Registration in global.asax:

            container.RegisterPerWebRequest<IBaseService<ApplicationContent>, RavenService<ApplicationContent>>();

2. Definitions:

    public interface IBaseService<T>
        T GetOne(string id);

    public class RavenService<T> : IBaseService<T> where T : Mutator
        private IDocumentSession _documentSession;
        public IDocumentSession DocumentSession
            get { return _documentSession; }

        public RavenService(IDocumentSession documentSession)
            _documentSession = documentSession;
            IncludeDeleted = false;

        public T GetOne(string id)

    public class ApplicationContent: Mutator
       .... (0nly properties)

Hope this is enough information.

Yours sincerely,

Evert Wiesenekker

May 27, 2011 at 6:27 AM

Hi Evert,

Most of the code snippets that you find in the documentation are unit tested (and can be found in de CodeSamples project in the source repository). One of the few snippets without unit tests is the PerWebRequest extension method. In a sense it's Murphy's law. There was a bug. Thanks for reporting this.

The top most extension method made the following call:

container.RegisterPerWebRequest(() => container.GetInstance<TImplementation>());

the C# compiler translates to:

container.RegisterPerWebRequest<TImplementation>(() => container.GetInstance<TImplementation>());

This makes TImplementation depend on TImplementation, which caused the cyclic dependency exception (Ninject would have thrown a stackoverflow exception in this case). The correct code is (of course):

container.RegisterPerWebRequest<TService>(() => container.GetInstance<TImplementation>());

I updated the wiki page with that code snippet. If you use the new code, it should succeed. If there any other questions, don't hesitate.

Happy injecting ;-)

May 27, 2011 at 7:26 AM

Thank you for your quick support and yes this change works! I could convert it from Ninject to yours in 1 evening. Maybe helpful for other people reading this post:

1. Ninject 'ToSelf'


Simple Injector equivalent:


2. Ninject provider

Bind<IInterface>().ToProvider(new IInterfaceProvider()).InRequestScope();

Simple Injector equivalent:

container.RegisterPerWebRequest<IInterface>(() =>
     ... (some code, for example load a configurationsetting ect)

    return instance;



May 27, 2011 at 10:33 AM

I designed the Simple Injector with migration in mind and created a migration guide for this, but I never expected anyone to switch from one of the popular frameworks to Simple Injector. Nevertheless I see it as a compliment that you did. The samples you gave can come handy for me, because the Ninject migration page is currently missing from the migration guide, mainly because of time constraints.


Marked as answer by dot_NET_Junkie on 11/3/2013 at 11:45 PM
May 27, 2011 at 11:54 AM

Here are my reasons:

1. Of course Ninject is very simple and readable too, but I got for my backend storage a nasty error related to Ninject did not clean up things when using Web Request object lifetime (it was for me difficult to track what was wrong). I also found it difficult to find Ninject examples in relation to 'normal' ASP.NET Web forms applications. Your documentation is very good at this point and you explained why I need a 'Global.Container' for a Web Forms app (very helpful). 

2. I tend to lean towards simplicity. I noticed a lot of frameworks are very big (with unwanted dependencies) and (at least for me) difficult to understand. Some are slow too I red (like Ninject).

3. You seem to update your product regularly.