# Saturday, July 14, 2007
Wasted 5 minutes figuring out what was going wrong, maybe this will save someone else the effort!

When using RhinoCommons and CastleProject both from trunk there's a version conflict with NHibernate.

RhinoCommons has NHibernate Version 2.0.0.1001 (Including support for things like Multi-criteria) ... and then the Castle Project is using NHibernate Version (1.2.0.4000) - this took me a little bit by surprise when I discovered that a monorail project I had was failing when attempting to databind properly when using the ARSmartDispatcherController... because I wasn't checking the binding errors collection, this was just failing silently... so a save would just load/save the existing record, without any binding.

Quick fix is just to use a assembly binding redirect in the web.config:

<runtime>

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">

        <publisherPolicy apply="no"/>

        <dependentAssembly>

            <assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4" culture="neutral" />

            <bindingRedirect oldVersion="1.2.0.4000" newVersion="2.0.0.1001"/>

        </dependentAssembly>

    </assemblyBinding>

</runtime>




posted @ Saturday, July 14, 2007 1:13:35 PM (New Zealand Standard Time, UTC+12:00)    Comments [4] | |
Thursday, July 26, 2007 9:33:28 AM (New Zealand Standard Time, UTC+12:00)
You seem knowledgeable here, maybe you can help.

I am using trunk ActiveRecord in an application. I would like to use Rhino.Commons as well, but there is a Nhibernate version conflict as you mentioned. Now looking at what you have here, would this apply to my situation?

I would like to stick to using NHibernate 1.2 as its a stable official release. I would also like to use some things in Rhino.Commons.
Christian
Thursday, July 26, 2007 10:45:10 AM (New Zealand Standard Time, UTC+12:00)
Well I believe some of the stuff in RhinoCommon's relies on the NHibernate Trunk (though I could be wrong) ... you could try replacing the NHibernate Lib's in RhinoTools and building it to see what breaks (and then remove those classes) - my work around only addresses the reverse problem (using the NHibernate Trunk + RhinoCommons with the Castle Project, when it's been built targeting NHibernate 1.2).

Generally speaking the easiest way to get up and running with both projects in my experience is.

Checkout CastleProject
Checkout RhinoTools
Replace the Boo Lib's in the CastleProject with those from RhinoTools.
Rebuild the CastleProject
Update the RhinoTools project with the Castle Assemblies you've just built.
Build RhinoCommons
Hack in the version redirection for your project (because the CastleProject was built with NHibernate 1.2)

You can build the CastleProject with the NHibernate Trunk, but that was giving me issues for a while so I reverted back to build with 1.2 and then replacing the assembly with the 2.0 NHibernate lib's in RhinoTools... seems to work just fine.
Friday, July 27, 2007 4:41:33 AM (New Zealand Standard Time, UTC+12:00)
Ok, thanks. I am no where near the coder Oren Eini is, or you that are most likely. I would not be comfortable running NHibernate trunk anywhere close to a production app. :)
Christian
Saturday, July 28, 2007 12:58:48 AM (New Zealand Standard Time, UTC+12:00)
I doubt you would ever strike a problem in the NHibernate Trunk that would cause catastrophic failure for a production site, if the site has passed all the automated tests, and satisfied the test team enough to end up being cut to production then it's hardly going to be a source of problems, especially if you only use builds from the trunk that have passed all the tests (which is what I normally do with the Castle project (though I only care about tests in the core/windsor and monorail... I don't use a lot of peripheral stuff).

Be careful when putting trust into stable builds, in a number of cases the trunk fixes bug's that are in the stable release but weren't identified or resolved in time - that's certainly the case with the Castle Project.
Comments are closed.
Search
FeedCount

Tags...
.Net (83) .Net Reactor (4) .net user groups (9) 2008SummerRoadTrip (1) ActiveRecord (1) architecture (1) architecture chat (95) ArchitectureCamp2007 (2) asp.net (1) Astoria (1) Auckland (1) base4 (9) batching (1) binsor (1) blog (4) boo (1) books (1) C# 3.0 (9) cambodia (9) CAML.Net (1) castle (40) china (8) codecamp (3) codeplex (3) dapper.net (1) DevDefined Ltd. (4) DirectShow.Net (1) DLR (1) DSL (4) EAUG (1) Enterprise Architect (5) Enterprise Architecture (1) Enterprise Library (1) F# (1) feedburner (2) first post (1) Friendster (1) generics (1) googlegears (1) hacks (3) hardware (3) hongkong (2) Horn (1) hyper-v (1) ideas (1) IoC (21) IronPython (13) IronRuby (2) jobs (1) Languages (2) laos (8) LINQ (7) LiveId (1) LLU (1) Local Government (1) MDA (1) MDD (1) microsoft (1) Model Driven Development (1) mono (1) monorail (2) Movies (1) Music (1) nDepend (1) news (1) NHibernate (3) NUnit (2) nvelocity (1) OAuth (6) office (1) OpenSocial (1) orcon (1) photos (1) php (1) PostSharp (1) powerpoint (1) presentations (1) ReSharper (1) REST (2) rhino commons (3) rhinomocks (5) Ruby (1) SaaS (1) scm (1) Screen Architect (0) SharePoint (5) silverlight (1) Splicer (4) SQL2008 (1) supcom (1) survey (1) svn (1) Syzmk (4) thailand (6) Tools (2) Tortoise SVN (1) trac (2) Travel (36) Unity (2) vietnam (7) vista (2) visual nhibernate (1) vmware (1) volta (3) VS2008 (1) WCF (3) wiki (2) wikipedia (1) Windows Server 2008 (1) windsor (6) WinForms (1) wix (2) WPF (2) xmlrpc (1) yahoo pipes (1)
Who am I?
Alex Henderson
Alex Henderson
Auckland, New Zealand
Managing Director at Dev|Defined Limited

"Self Confessed Coding Junky for 15 years"
View Alex Henderson's profile on LinkedIn
 
Mobile: +64-21-402-969
Email: bittercoder 'at' gmail 'dot' com
MSN: bittercoder_nz@hotmail
Skype: alex.devdefined
Navigation