Getting the latest MVCContrib, NHibernate and Castle to play nicely
I’m using the latest versions of NHibernate (3.0.0), MVCContrib (2.0.96) and Castle Windsor (2.5.1) in a new project I’ve just started. Sometimes when you’re playing with the cutting edge releases of open source products, things don’t always work well together.
After putting everything together, ASP.NET gave me a Yellow Screen of Death:
This is the framework trying to tell you that one of your dependencies is looking for a specific version of a library and the runtime is unable to find that particular version.
Quick Tip #1: How do I figure out what the dependencies are?
Use ildasm to open up the assembly and take a look at the assembly manifest. This will tell you exactly what the dependencies of an assembly are. Looking at the dump for the latest release of MVCContrib.Castle tells us that it needs an old version of Castle:
Ordinarily, you would resolve this by doing what’s called an Assembly Binding Redirection by sprinkling some magic dust that looks like this in the <runtime> section of your application configuration file:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Windsor" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
<bindingRedirect oldVersion="2.1.0.0" newVersion="2.5.1.0" />
</dependentAssembly>
</assemblyBinding>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
<bindingRedirect oldVersion="1.2.0.0" newVersion="2.5.1.0" />
</dependentAssembly>
</assemblyBinding>
With this in your config file, the framework will now force dependencies to use the newer version of the library.
Unfortunately, in this particular case, using this workaround only leads to another Yellow Screen:
In case you haven’t figured it out yet – now you’re really in trouble.
This message is telling me that MVCContrib is using a method that is no longer available in the newer release of Castle Windsor. At this point, you have three options:
- Don’t use the latest versions of everything. Go back to earlier releases of all your dependencies until you find a sweet spot where everything works well with everything else.
- Wait for all the libraries you’re dependent on to catch up with each other and use the official releases
- Tweak the code and roll your own release
Of course, I went with option three.
I got the latest code from the MVCContrib Mercurial repository. A quick look at the project tells me that the problem is in the WindsorExtensions.cs file in the MVCContrib.Castle project. I also notice that the MVCContrib.Castle project is dependent on a couple of other Castle components:
I downloaded these off of the Castle website and copied over the framework 3.5 binaries to the bin folder in the MVCContrib source tree. I did a recompile at this point and the build was broken. This is a good thing because it means it’s picking up the new files that I just copied.
The project was broken in two places – one was WindsorExtensions, which is what I want to fix. The other was WindsorModelBinder. I have no use for this, so I just took it out of the project and went back to fixing WindsorExtensions. A quick update to the RegisterControllers method got everything to compile again:
public static IWindsorContainer RegisterControllers(this IWindsorContainer container, params Type[] controllerTypes)
{
foreach(var type in controllerTypes)
{
if(ControllerExtensions.IsController(type))
{
container.Register(Component.For(type).
Named(type.FullName.ToLower()).
LifeStyle.Is(LifestyleType.Transient));
}
}
return container;
}
Now I took the new binary, popped it into my project’s dependencies folder, crossed my fingers, and ran the project. Everything works! So, after an hour of digging through the dirt I now have a project that uses the latest versions of MVCContrib, NHibernate and Castle to work with each other.