Options for wiring dependencies with NInject

With NInject (preferably 2.0), what options do we have wrt wiring up our object dependencies in a web application?

Can they be defined in an XML configuration file?

Or does i开发者_JS百科t have to be done via code?

---

There is an extension for xml based configuration: https://github.com/ninject/ninject.extensions.xml

You can do a lot more powerful binding in code though.

---

Ninject doesn't have XML configuration, sorry but I can't provide a direct link (cos their site has flash elements), but here is a quotation from ninject.org:

Free yourself from XML

Most other .NET dependency injection frameworks are designed around the use of XML to declare type bindings. Rather than forcing you to write cumbersome and error-prone text, Ninject arms you with a fluent interface, which lets you connect the pieces of your application using full-fledged code. This means you can take advantage of the features of the IDE and compiler, like code completion and type-safety.

---

The problem I see with defining bindings in the code only is that you have to add reference to the dll. You cannot change the binding without adding reference to new dll (removing reference to old one), change code and recompile.

If we had xml config I wouldn't need reference at all, and wouldn't have to recompile. Right now I have MVC app that is using DI to pass repositories to Controllers. Nothing else then Ninject code for adding bindings uses the concrete implementations of repositories. And still I need to add reference to dll containing the implementations. For only one line of code!

Or maybe there is a possibility to achieve this using Ninject?

---

What are you looking to achieve? What sort of stuff are you looking to configure? Dynamically selecting a Strategy ? Passing in Port numbers? You could offer a lot more information as to what you're thinking in order to get a better answer [that you can acccept :P].

You need to split the concerns of:

1. known object wiring (DI)
2. configuration - generally you'll want to split those into small focused subsets e.g. Strongly Typed config elements vs having a global pool of settings in a big pile mishmashed together a la appSettings
3. plugins / unknown object wiring (MEF?)

In the first pool, doing it in Code is just the right way and I cant think of any advantage XML would give, esp. in the context of strong names etc.