Tips for fixing problems with dll versions in .NET.

Question

I just got started with the basics of NHibernate, and, refactoring data access and domain levels, I thought I could get pretty and start using dependency injection for the data access level. Unit testing here we will come!

I thought that since NHibernate uses many Castle gateways, I could also use Castle Windsor for the DI container. Just as I ran the application to check if everything worked, I got a link to the dll link.

Since I'm using NHibernate 2.1.2.4000 , I already have a link to Castle.Core 1.1.0.0 . However, the version of dll Castle Windsor used by me ( 2.1.0.0 ) says that it wants Castle.Core 1.2.0.0 .

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

Alternatively, how do I know if NHibernate will work with Castle.Core 1.2.0.0 , or if it breaks?

Thanks for your help.

David

Answer 1

The short-term solution uses assembly binding redirects.

The best alternative is to compile NHibernate from source using the correct version of Castle.

Answer 2

There is a new open source project, Refix , which was created to help with this very problem.

This helps in several ways:

• It "reflects" all the projects in your development solution if there is a common set of dependencies that can be "agreed upon" by all projects. If so, it can update project files accordingly.

• If not, but some versions of the dll are compatible with other versions, it can automatically update your configuration files using the appropriate build redirects.

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

This project is new and only in alpha, but it is certainly functional and definitely worthy of attention. In addition, the author (whom I know personally) is very interested in receiving feedback and ideas on the project.

It's worth a look IMHO.

Answer 3

I don’t think NH can refer to Castle.Core, you have the opposite situation: The active record, which is part of the castle project, needs this version of NH. To make links consistent, you can try downloading all the assemblies from the lock family to match the latest (Windsor in your case). This will require some regression testing and possible build problems. Alternatively, you can recompile Windsor without requiring a specific version of Castle.Core, but given such a big difference in version, you are likely to run into several compatibility issues or even build problems due to an API change.

Answer 4

Well ... you can solve problems with the version ... or you can install them all in the GAC and stop worrying about it.

This makes the installation process less portable, but should do the trick.

Answer 5

This may be possible using assembly binding redirection; See here for more details.

Answer 6

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

[Edit: there are answers that I did not see when I added this, which may also fix the problem.]