I'm having a problem integrating a library our company has built which uses Solrnet in the back end. We have many other libraries, one of which uses NHibernate for the database. It all works fine, the library gets the data back.
When we add a reference to this new library which uses Solrnet, things start to go arwy. The first error that occurs when we run the application. when the application runs the StructureMap registry for the library using NHibernate, the registry blows up because NHibernate can't load the Castle.Core assembly (which has not caused any problems being missing prior to adding the reference). If we then ensure that Castle.Core is present, NHibernate then blows up trying to load Castle.Windsor, which again it didn't need before.
Any ideas? As I said, the library which uses NHibernate is fine if we remove the new library which uses Solrnet, but as soon as we reference it things start to go wrong. The library which uses Solrnet also configures Solrnet using StructureMap, FWIW.
EDIT: These are the versions of various assemblies in the mix. StructureMap - 2.6.1.0 Fluent NHibernate - 1.0.0.0 NHibernate - 2.1.2.4000 Solrnet - 0.3.1.0 Castle.Core (came with NH) - 1.1.0.0
UPDATE: Its starting to look like Solrnet is the one trying to load Castle.Windsor. I'm not sure why as we've given it a StructureMap configuartion. Its mere presence is enough to blow things up. Even without the assemblies which depend on Solrnet, the fact that its there at all seems to mess with the NHibernate configuration.
Ok, I figured out how to stop this error. We were using the merged Solrnet.dll, which includes all the types for connecting to other Ioc containers as well as NH integration. I switched to using the unmerged binaries, which keeps the other Iocs in separate assemblies, and we only included the base Solrnet.dll and StructureMap.Solrnet.dll, which solved the issues mostly. I still did have to be sure to include Microsoft.Patterns.ServiceLocater, as the base Solrnet.dll still exposes this. Not ideal as we're not using it, but better than needing a bunch of other assemblies.