Rolling out an update of Castle just got a whole lot easier
I
just released yesterday, that the recent change to NHibernate that removed all dependency from any kind of “Proxy framework”, has made it a whole lot easier to rollout a fresh build of the Castle trunk to the Enterprise.
(see this post that describes the change that I'm talking about)
Prior to this change, NHibernate
had a hard dependency on Castle. The problem however, was that some of
the projects in Castle also has (and still does) have a dependency on NHibernate. This circular dependency lead to the following build cycle:
1) Download Castle 2) Download NH-source of the release (here you need the sources of NH) 3) build Castle.Core + Castle.DynamicProxy2 (because NH2.0.1 has a reference to both) 4) copy Castle.Core.dll + Castle.DynamicProxy2.dll to nhibernate\lib\net\2.0 and nhibernate\lib\net\3.5 5) build NHibernate 6) build all other Castle stuff
(thanks to Fabio Maulo who described this to me)
Ok,
so these build steps can be automated (and I believe Rhino.Tools has
such a script). The real problem however, is that in order to rollout a fresh build of castle you HAD to re-build NHibernate (or face having to deploy assembly binding re-directs) if both Castle and NHibernate are used within the same solution.
In practice the pain did not stop there. Being forced to rebuild NHibernate, you had to then ensure that these updated NHibernate assemblies were rolled out to all your other projects that required NHibernate. Either that or face having to maintain multiple versions of NHibernate / Castle across multiple source control repositories.
All because you wanted to update Castle!
This is a thing of the past for NH2.1.0 (or the current version of the NH trunk). Now, to rollout a fresh build of the Castle trunk you do the following:
