+1  A: 

You shouldnt need to introduce a default ctor just to please Ninject.

Assuming you're using V2, the semantics for how a constructor is chosen are detailed here

(BTW By default, the string type is not treated as a resolvable type OOTB, but you should be able to Bind ContentType To something and have that constructor invoked).

If none of the above gets you moving, can you please supply a usage scenario and/or an exception detailing the issue you're having.

Ruben Bartelink
I've updated my code and provided the exception from Ninject.
mare
@mare: In your Module, you need to do a `.WithConstructorArgument` or something similar so that Ninject knows what to put into the constructor parameter - it can't just guess. If you know up front, you might be able to `Bind` `ToMethod` instead of `To<T>`.
Ruben Bartelink
In summary, you need to tell Ninject, via your `Bind` statement, how it's going to get each dependency so that it can create a `new` `PageController` - the same you'd have to if you needed to `new` one up, e.g. for a test?
Ruben Bartelink
If I continue on the above code and do this in my Ninject ModuleBind<IRepository>().To<XmlDefaultRepository>().WithConstructorArgument("contentType", "Page");then it works, however the thing is, I cannot bind my contentType constructor parameter just to "Page" in my Module. This constructor parameter is controller dependant. So in my PageController, XmlDefaultRepository would be instantiated with a "Page" value for contentType but in some other controller like a ServiceController, the "contentType" parameter value should equal to "Service".
mare
Hopefully you understand I therefore cannot hardcode the value for "contentType" parameter in the Module. How can I solve this problem? What's the thing about controller factories etc.?
mare
IIAC, you can use the .When and .Only etc. to say "when the context says that we're injecting into an X" - one can then put in spearate `Bind`ing registrations for each context. That route will work fine as long as everythign can be known at the time of controller instantiation. If it's only clear at the time the action gets invoked, then it needs to become a param. But I'm sure you figured that out. Huighly recommend looking at the Ninject unit tests to see examples of all the sorts of things you can do around this sort of thing.
Ruben Bartelink
Your suggestion to look at Ninject.Tests helped a lot though some methods like WhenClassHas are not being tested. But this was the method that, in conjunction with class attributes, worked for me.
mare
@mare: Great stuff - It's mainly prodding like this from @Ian Davis that led me there (I used to use reflector on Ninject and disregard the tests). Now you have the baton of replying to Ninject questions on SO with USL comments and/or go to the mailign list :P
Ruben Bartelink