Ninject - How to identify which class is throwing exception during construction

Question

We're using Ninject 3.0 to resolve a class. Fairly boring standard stuff:

IKernel kernel = GetKernel(); 
var foo = kernel.Get<IFoo>(); 

However on one particular machine, we're getting an exception when constructing... something. We know what's blowing up, but it's in the logging framework (Common.Logging), and that code is used throughout our codebase, in all/most of the constructors.

Other than putting every single constructor in a try/catch and wrapping the exceptions with type info, I get no useful information from Ninject as to what it's having trouble with.

Is there some way I can get Ninject to tell us which class that it's failing to create?

Another person asks a similar question, but their solution doesn't help - we are getting the exceptions from the logging framework, not Ninject.

Taxpayer

Please show us the stack trace including the stacktrace of the inner exceptions. This information should contain the constructor of the class that failed to initialize. – Prytaneum

The class that failed to initialise is exactly what I'm trying to get Ninject to tell me. It doesn't give that class. – Taxpayer

Sounds like a bug in Ninject to me. Ninject should wrap the thrown exception. You should report this as a bug to the Ninject team. – Prytaneum

Do you see any first-chance exceptions being raised? – Stook

Unfortunately not, @Stook – Taxpayer

Have you tried to turning on Common Language Runtime Excpetions and Managed Debugging Assistans under Debug/Exceptions? – Durga

@Prytaneum I just verified that Ninject doen't swallow any exception. There is one exception: When you call TryGet it will swallow the exception because that method must return null if it can't resolve an instance. If the exception is swallowed then it must be somewhere in the application/logging framework code. Otherwise you should get an exception when calling Get. – Helen

Will, you might want to try registering to the AppDomain.FirstChangeException event to find out where this exception is thrown. – Prytaneum

Answer 1

This isn't really a solution but when I've had problems I've manually deleted constructor dependencies one at a time until I've found the problem dependency. When I verify all works without that one dependency, I then go into that concrete implementation. I essentially recursively, from the entry point go down through each dependency, removing each dependency until the unbound dependency is identified. Tiring, but brute force hasn't failed me yet. Even when I encountered a private constructor being the cause of a problem, I'd never of gotten that without brute force. More commonly though, it's an unbound type somewhere or a conditional injection.

Conium

Yeah, unfortunately sometimes this occurs in really large systems - and the number of dependencies can reach into the many hundreds if not thousands. – Taxpayer