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.
Related
We're using NH 2 and need some features from NH 3 (JOIN ...AND (...)). It's quite easy to copy them from sources. So I wonder if there can be any unexpected errors in application after recompiling NH 2 and using instead of the one compiled by developers of NH.
Problems may occur if you have other pre-built assemblies which reference a specific NH version. In that case you may need to do an assembly binding redirect. Personally, I would try to upgrade everything to NH 3 if I wanted a feature from it because that way I don't have to concern with managing a forked version of an assembly.
Is it possible to pre-generate lazy-loading proxies under NHibernate 3?
NHibernate 2 supported this via NHPG but NHPG hasn't been updated for NH3 that I can see. Downloading the NHPG sources and blindly changing the assembly reference from NH2 to NH3 blows up; NH3 has built-in proxy generation and stuff has been reorganized.
How are people (pre) generating lazy proxies under NH3?
I've updated NHPG to support NHibernate 3.3.1 GA.
You could grab the sources here: https://github.com/NHibernate-Contrib/NHibernate.ProxyGenerators
You have to build it by hands (download the sources and run package.cmd) for now until we release an official version.
I don't know if this answers your question since I do not see any tag related to language that you are using.
In .NET, I use Fluent NHibernate and POCO objects. Don't know if there is a tool to upgrade your XML files to POCO classes to use with Fluent NHibernate.
I'm migrating my solutions from .NET 2.0 to .NET 4.0. I open the solution file in VS 2010 and follow migration wizard.
While building the solution and comparing the changes with the server copy (since solution is under source control VSTS), I surprisingly found that
1) the public classes were changed to 'internal' and
2) the 'public static' properties were changed to 'internal static'
It gave me problem because the output assembly is referred in other projects.
Can someone explain why does it happen? Also, are there any other such changes taking place behind the scene? Or Am I doing something wrong ?
(Note: I have ReSharper 5.1 installed but I think it has no place in this case.)
ReSharper may have given the suggestion to make methods static for those methods which are not using any instance variable or method within it. This is what I have observed.
Similarly, if the methods are not accessed from any other project/assembly, it may give you suggestion to make them internal.
I'm migrating the data layer of our application to NH version 2.1.0 (from 2.0.1) and noticed the use of LinFu. I discovered that framework and want to use it in other pieces of the application, especially I want to use the LinFu.Reflection.dll, which requires a reference to LinFu.DynamicProxy and here comes the trouble, the 1.0 final version of LinFu that I can find on google.code is not the same version used by NHibernate itself. Do I need to rebuild NHibernate.ByteCode.LinFu.dll changing the reference to the available version? If not, what else?
I have faced the same problem a few days ago. There's a tool named ILMERGE that merges .NET DLL-files, and that way you should be able to have several versions of the same DLL in your application.
Unfortunately I haven't tested the tool yet, I didn't get around to it, but I'll test in the next week.
But Rhino Mocks for example, has a binary with all dependencies included: http://ayende.com/projects/rhino-mocks/downloads.aspx, so it seems doable.
I've been having tons of problems getting the non-xml configuration for Castle Windsor set up working properly. In the meantime I've seen more and more people giving advice via the Windsor Container fluent interface. I've been Gooogling about for the last day and I cannot find this API anywhere.
I am talking about the key .Register() method which seems to be an extension method to the IWindsorContainer object. It seems like it might be in the Castle.MicroKernel.Registration namespace, but I cannot find the corresponding library anywhere!
Also, is there any place where I can find documentation for this stuff?
EDIT:
I found that the copy of Castle.MicroKernel in the sample project here has more namespaces then the one I was using (even though this one is eight days older and v1.0.0 whereas mine is v1.0.3...), still having trouble finding the .Register() method or any samples though.
EDIT:
I found some fluent interface samples at Bitter Coder, no downloadable samples though so I'm still at a loss.
Edit Again: Finally got it. The most recent source code for castle windsor is available here, get the most recent successful build, inside the zip file is a bin directory. The fluent interface is inside Castle.Microkernel (you will probably need to reference Castle.Dynaproxy, Castle.Dynaproxy2 and Castle.Windsor too).
PS This post is the #1 Google result for "castle fluent interface documentation" sad guys, you need to get on that. Crickets chirp What's that? Fine. Let me figure this out then I'll get on it then.
The Fluent interfaces were introduced a while ago - but are only available on Trunk (after RC3) either grab the castles sources (from the projects subversion repository) and build the IoC projects yourself from here, or easier still grab the latest successful build on the continuous integration server and use that.
Castle.MicroKernel.Registration is the name space you'll need to use, in the MicroKernel assembly - once you have a reasonably fresh build of Castle you should be able to find Register(...) methods on both IKernel and IWindsorContainer interfaces, allowing the application of "registration components" (anything which implements IRegistration) which includes the various fluent component registration features in Castle, as well as anything custom you might develop.
The best place to ask questions regarding Castle is the google castle-project-users and castle-project-devel groups - keep an eye out for Craig Neuwirt in particular as he's the core developer working on the fluent interface features in Castle Windsor, and so is best equipped to answer questions about the various fluent interface features, as they are not widely documented yet.
Ok, so just for reference. Official, complete documentation for the API is on Castle Windsor Documentation Wiki