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.
Related
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 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.
I would like to get all 3 of these libraries working together but have a version problem.
Latest version of Linq To Hibernate (1.0) came out on 2009-07-26 and works with NHibernate 2.1.0 afaik. Fluent NHibernate's oldest release on the other hand is for NHibernate 2.1.2.
Google search yielded this zip file of binaries compiled together but it's somewhat outdated (2009-07-19). I'm not sure downloading the latest source code of each project and trying to build them together will work or not, I'd rather not to go that way unless I have to.
I guess the weakest link in this combination is Linq To NHibernate and maybe I should think of leaving it outside if there isn't an active community effort.
In short: Does anyone use these libraries together and if so, how did you solve this issue? Do you build it all yourself?
Note:
Looks like a duplicate of this question but it has been 1 year since it's answered, and the links given in the accepted answer don't work anymore.
NHibernate ver 3 has been released which already has the linq libraries. Download the latest binaries.
I don't think Fluent has been updated to use 3 yet so download the latest source for fluent and replace the NHibernate assemblies with the new NHibernate version 3 assemblies. You will need to tweak the source ever so slightly so that it compiles. Compile it in release mode and grab the output from the project bin folder.
It has been working fine for us.
EDIT
As Kohan pointed out you can download the latest version of Fluent 1.2 with the latest version of NHibernate 3 from the link to Fluent NHibernate I provided earlier.
What is the last version of nhibernate that supports .Net Framework 2 ? and is there a big difference between dealing with it and dealing with last version that supports .Net 3.5 ?
Note:
The series NH2.1.x is the last whose
target is .NET2.0
NHibernate 3 Alpha (full .NET Framework 3.5 support):
With the 3.0.0 release, NHibernate
includes support for LINQ, along with
additional features such as:
Along with a long list of bug fixes
and improvements, it has several new
features including a new strongly
typed criteria API called QueryOver;
lazy loading of columns; alias
delimiting in generated SQL; and
support for DetachedCriteria within
IStatelessSession. The new release
also brings improved support for LINQ,
overcoming the HQL limitations of the
previous provider.
Upgrading users should be aware that
one of the fixes means that null
values in dictionaries are no longer
silently ignored, which has the
potential to break existing
application code.
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.