views:

134

answers:

6

Hi all

I've just got to grips with the basics of NHibernate, and while refactoring my data access and domain layers I thought I might as well get cute and start using dependency injection for the data access layer. Unit testing here we come!

I thought since NHibernate uses loads of Castle dlls I might as well use Castle Windsor for the DI container. Just as I was firing up the app to see if it all worked, I got a dll reference issue.

Since I'm using NHibernate 2.1.2.4000, I already have a reference to Castle.Core 1.1.0.0. However, the version of Castle Windsor dll I am using (2.1.0.0) is telling it wants Castle.Core 1.2.0.0.

I'm kind of new to this crazy open-source class library malarkey. In general, how do I find out what the dll dependencies are for something in advance, and how do I find the version of Castle.Windsor which uses Castle.Core 1.1.0.0, which is the one I already have?

Alternatively, how do I find out if NHibernate will work with Castle.Core 1.2.0.0, or if it will break??

Thanks for your help.

David

A: 

I don't thing that NH could reference Castle.Core, you rather have the opposite situation: Active record which is part of castle project needs that version of NH. To make references consistent you can try to download all assemblies from castle family to have them matching the newest (Windsor in your case). That will require some regression testing and possible build issues. Alternatively you can recompile Windsor without requirement of specific Castle.Core version, but given such a big version difference you will probably face multiple compatibility issues or even build problems due to API change.

Alex Krupnov
NHibernate uses it if you use Castle.DynamicProxy to generate proxy classes for lazy loading.
David
ActiveRecord is in a separate assembly from Castle Core, so this is not the reason Alex. David is correct, NHibernate uses Castle DynamicProxy
nocache
To be totally precise, NHibernate in version 2.1.2 introduced the ability to select the dymanic proxying library you use to generate proxies around your domain classes. One option is Castle, which would therefore give you a reference to the Castle libraries. Another is LinFu, which seems to be what David has gone for (and, for what it's worth, what I have typically used, as I use LinFu for other things as well).
David M
A: 

Well... you can deal with the version issues... or you could install them all in the GAC and stop worrying about it.

That makes for a less portable install process, but should do the trick.

Randolpho
I really don't want to do that for the reason you mention.
David
+1  A: 

A short term solution is using Assembly Binding Redirection.

A better alternative is compiling NHibernate from source using the Castle version you want.

Diego Mijelshon
How would I do that? I mean, I know how to download the source and build, but presumably I might encounter API changes as mentioned by Alex Krupnov. I am but a humble web developer; I don't know NHibernate or Castle well enough to fix that sort of thing.
David
Wow! It looks pretty straightforward though. If I encounter this sort of thing again, I'll check that out! Thanks!
David
A: 

This may be possible using an assembly binding redirection; see here for details.

DanP
A: 

Well apparently there's nothing certain you can do about it, so I've switched NHibernate to use Linfu instead of Castle for dynamic proxies and now I'm free to have a more up to date version of Castle.Core in my solution.

[Edit: there are responses that I hadn't seen when I added this, which may fix the problem also.]

David
+1  A: 

There is a new open source project, Refix, that has been created to help with this very issue.

It helps in several ways:

  • It "reflects" over all the projects in your solution to work out if there is a common set of depenencies that can be "agreed on" by all projects. If so, it can update your project files accordingly.

  • If not, but certain versions of dlls are compatible with other versions, it can automatically update your config files with the appropriate assembly redirects.

  • It also acts as a central repository for all your various assemblies and their versions.

This project is new and in alpha only, but it certainly is functional and definitely worth a look. Additionally, the author (who I know personally) is very keen to get feedback and ideas on the project.

This is well worth a look IMHO.

Rob Levine
This sounds like an amazing project. If I have a chance, I will have a look and provide some feedback.
David