Where exactly is the difference between IoC and DI

In common usage, the terms have become somewhat synonymous. The original idea of IoC -- Inversion of Control -- was very much related to the "Hollywood Principle:" Don't Call Us, We'll Call You.

In traditional applications, developers would write business code and framework code. The business code would then call the framework code to accomplish tasks. Under an IoC model, you "invert" that model and create a framework that accepts business modules and calls them to accomplish tasks. This principle is exhibited in several development frameworks including the old Smart Client Software Factory and the newer Prism (or Composite Applications for WPF/Silverlight). In these models, the UI Modules are registered with an IoC Container and loaded as needed based on configuration and user actions. While powerful, these models also tend to have a very steep learning curve.

Dependency Injection is a technique (hard to call it a pattern, really) of removing internal dependencies from implementations by allowing dependent objects to be injected into the class/method by an external caller. IoC frameworks use dependency injection to supply user modules and other dependent code to framework routines that "glue it all together." Dependency injection is used heavily by IoC frameworks because that is the mechanism that allows them to "Call You."

IoC Containers, such as Castle Windsor and Structure Map help with dependency injection by providing automatic instantiation and lifecycle management of classes you register -- including automatic instantiation and injection of parameters required by registered classes. All of this makes it easier to use dependency injection, but is not required.

Dependency Injection is a mechanism for flexibility that maximizes dependency on Interfaces while minimizing dependency on specific implementation. Consequently, systems that use dependency injection can support "pluggable" implementation classes that can be used depending on circumstances. A very big benefit of this "pluggability" is that it makes creating Unit Tests much easier. You can mock an object to the needed interface, then inject it into your test object.

So, IoC is really the broader principle and DI is a fundamental technique within. IoC (Hollywood Principle) systems tend to be pretty complex, can be hard to understand, and thus have steep learning curves. DI, on the other hand is a good practice for everyday developers. I tend to prefer understandable and clear over cool, but complex.

IoC is the ability to vary the implementation of a contract.

DI is the ability to supply the implementation.