Both interfaces contain method(s) accepting, among others, an HttpRequestMessage. The trick here is to use the HttpRequestMessage’s extension method GetDependencyScope for resolving controllers (instead of using a DI Container directly).
Internally, the GetDependencyScope method uses the DependencyResolver (registered in the GlobalConfiguration instance) calling it’s BeginScope method which creates a new resolution scope. Objects that are resolved in that scope are tracked internally. Once the scope is disposed, those objects are released (using the container’s Release method).
Below is an implementation of the IDependencyScope interface:
Having a custom implementation of the IDependencyScope interface, we can now move on with the implementation of the IDependencyResolver interface. The recommendation (from the source code) is to return a new instance of IDependencyScope every time the BeginScope method is called.
An implementation of the IDependencyResolver interface for Castle Windsor could be similar to the one below:
As we can see, the BeginScope method returns a new instance of IDependencyScope which can resolve and release objects that belong to that scope.
Moving next, when upgrading from Beta to RC there might be another thing to consider. Since the IHttpControllerFactory interface has now been removed, implementations of that interface were using the controllerName in order to resolve component instances from the DI Containers. As a result, controllers were registered in the DI Containers using names for each registration.
A DefaultHttpControllerSelector derived type could be similar to the one below:
Make sure to register the above type in Castle Windsor otherwise the framework will pick it's default implementation.
All the above information is the result of browsing the source code on CodePlex. If any articles or blog posts are released (by the ASP.NET team or individuals) I might create a new post with updates, if necessary.