Bonus Bits

Using the Web API Dependency Resolver with Castle Windsor

In this post I will discuss a possible solution for having Castle Windsor resolving types for both MVC controllers and Web API controllers. Since the former is well known I will focus mostly on the Web API part.

A team building a mobile web application uses the ASP.NET MVC stack combined with another web services framework. With the release of the Beta version of ASP.NET MVC 4 they decided to give Web API a try (side by side with MVC controllers) and see if it fits their needs.

The Controller-derived types are used only for rendering the views (the code is written in JavaScript) while the ApiController-derived types are used for returning  data to the client.

The DependencyResolver class provides a method called SetResolver which acts as a registration point for resolving dependencies.

Be careful as there are more than one DependencyResolver types. One defined in System.Web.Mvc namespace and one defined in System.Web.Http namespace. We need the latter here.

Once we define the delegates and set a breakpoint we can see what types the framework requests.

At first an instance of the IHttpControllerFactory type is requested:

Followed by a request for an instance of the ILogger type and so on.

The first thing we want to do is to create a type implementing the IHttpControllerFactory interface.

Note that inside the WindsorHttpControllerFactory class the CreateController method  takes a string for the name of the controller. That means we need to use the Windsor's Named method to set a name for each controller registration. (We can also trim the "Controller" part from the name and also pluralize the remaining part.)

Let's also create a NullLogger implementing the ILogger interface.

For all the other instances that the framework requests there are default implementations in the System.Web.* assemblies and we can now create a Windsor Installer to encapsulate the registration logic.

In the Application_Start method we add the installer and set the delegates for the SetResolver method. That way when the framework requests an IHttpControllerFactory instance, Windsor will supply the one we created earlier.

In order to have Windsor resolve regular controllers (side by side) we can create and add another installer as well as an implementation of the IControllerFactory interface.

Finally, a gist with all the source code can be found here.

References:

• Web Api / Implementing IHttpControllerFactory.CreateController
• Web Api / How do I use Windsor?

Enterprise Library IContainerConfigurator implementation for Windsor

Alternative title: "Error Management Is Sometimes Exceptionally Difficult, Part 2"

    I previously tried to write an implementation of the IContainerConfigurator interface. The most tricky part was extracting the container registration entry for constructing a specific type. The entry is provided in the TypeRegistration class as a LambdaExpression and additional metadata.

    The fact that EnterpriseLibraryContainer class is completely decoupled from a specific container implementation made me keep trying to figure out a way to get the entries from the LamdaExpressions.

I posted two questions on StackOverflow, and I got all the necessary info:

• Architectural Refactoring overview (from this question).
• Use of the ParameterValue subclasses combined with the Visitor pattern over ParameterValues to make the code cleaner (from this question).

The support I had from the project team members  was accurate and detailed. That was great.

The current implementation relies heavily on Windsor's Property classes and it is based on the UnityContainerConfigurator.

Below is the WindsorParameterVisitor,

The ParameterValueVisitor class is needed because most TypeRegistrations are quite complex coming with both ConstructorParameters and InjectedProperties and all this stuff must be routed on the .DependsOn() method of Windsor (actually Castle.MicroKernel).

Below is some basic setup for configuring the Enterprise Library to use Windsor,

I haven't tested (yet) this code with all application blocks. I tested with Exception Handling application block and I was able to resolve the ExceptionManager class. I will try to post any future updates.

The source is on github.

Error Management Is Sometimes Exceptionally Difficult

    Update:  Please also read Part 2. The source is on github.

    I tend to simplify exception handling at layer boundaries, when designing a distributed application. Most of the time if an exception is propagated there I try to apply some kind of policy in order to log the exception and then re-throw  a different exception.

    When I started using the Exception Handling Application Block from Enterprise Library I found out that I had to also deploy the Unity assemblies.

The call below resolves the registered component for the ExceptionManager class:

EnterpriseLibraryContainer.Current.GetInstance<ExceptionManager>();

The IServiceLocator.Current property of EnterpriseLibraryContainer class sets by default the Unity container (via UnityServiceLocator adapter class).

In fact, if I remove the Unity assemblies a FileNotFoundException is thrown, indicating that Microsoft.Practices.Unity assembly or one of its dependencies could not be found.

Since I use Windsor in that application I didn't like the fact that I had to deploy it with two different IoC containers (!) so I started figuring out how I can call tell the EnterpriseLibraryContainer to resolve the ExceptionManager component using Windsor.

The first thing I did was to compile the Windsor adapter of the CommonServiceLocator against the current version of Windsor that I use (and also run the unit-tests and see if they pass).

Next, I set the IServiceLocator.Current property of the EnterpriseLibraryContainer class:

EntLibraryContainer.Current = new WindsorServiceLocator(container);

The last thing I did was to call the ConfigureContainer method on the EnterpriseLibraryContainer class. This method takes an IContainerConfigurator and an IConfigurationSource as parameters.

Great, so I had to provide a class implementing the IContainerConfigurator interface for the Windsor container.

The IContainerConfigurator interface contains a single method: 

void RegisterAll(IConfigurationSource configurationSource,        

                 ITypeRegistrationsProvider rootProvider);

Here is my (currently incomplete) implementation:

I really don't know what to do in the case of a MethodCallExpression as you can see inside the else block. However, after I can finish with the code inside that block I will be able to do this:

I will try to update the code as soon as I have done any changes.

Building Castle ActiveRecord from Source at GitHub

With Castle ActiveRecord you won't have to learn NHibernate mapping schema to have a working data access layer in minutes. For most cases you won't need to deal with ISession and ISessionFactory. Most of the complexity is handled by ActiveRecord, but if you want to do something more advanced, you will be able to do it.

via www.castleproject.org

To follow the steps described in the post you will need:

• TortoiseGit
• msysgit

Visit https://github.com/castleproject/Castle.ActiveRecord and copy to clipboard the URL for Read-Only access.

Create an empty directory and select the entry named "Git Clone..." on the Windows Explorer Context Menu.

 

Click OK in the next screen and wait while Git is downloading the project files.

When finished, you can browse the project files in the specified directory.

 

The default is to build for version 4.0 of the .NET Framework. If you need to build for an older version you can edit the build.cmd file (it is actually a batch file).

The project's build platform is MSBuild as you can see from the Console Output above.

 

Open folder "build" which is the project's build output.

 
As you may notice, the project now uses Remotion's re-linq provider.

To have a working data access layer in minutes, add a reference to Castle.ActiveRecord.dll and Castle.Components.Validator.dll. 

The documentation is here. Feel free to contribute.