Castle Versioning

5 views
Skip to first unread message

Paul Cowan

unread,
Jan 20, 2010, 4:39:58 AM1/20/10
to horn-dev...@googlegroups.com

Hi all,

I think the following problem might be interesting to both Castle members and horn members.

The splitting of castle into its various subprojects has inevitably led to some problems with dependency versioning.

I am a big Castle fan and use the following items of the castle stack in my day job:

Castle.Core
Castle.Components.Validator
Castle.DynamicProxy
Castle.Facilities.AutomaticTransactionManagement
Castle.Facilities.NhibernateIntegration
Castle.Facilities.WcfIntegration
Castle.Services.Transaction
Castle.Windsor

I am assuming this might be reasonably common amongst some castle users like myself.

When Castle was 1 big monolithic solution, you could at least guarantee that every castle subproject would be using the same version of other castle subprojects or the solution would not compile.

As Castle has now split into the various subprojects, they will of course naturally grow orthogonally without the same compiler checks in place to ensure unity.  I had sort of been hoping that Castle might try and resolve the dependencies of the subprojects by compiling the projects and copying the .dlls into the various lib folders during the CI build or maybe use horn. 

As you would expect, the projects and their castle dependencies are now failing to compile together. 

If we use the Castle.Facilities.WcfIntegration as an example, it had the following dependencies section. 

dependencies:
    dependency "castle.core" >> "Castle.Core"
    dependency "castle.windsor" >> "Castle.DynamicProxy2"
    dependency "castle.windsor" >> "Castle.MicroKernel"
    dependency "castle.windsor" >> "Castle.Windsor


You can see that it has a dependency on the Castle Windsor project:

A couple of days ago, the WcfIntegration facility stopped compiling against the latest MicroKernel dependency from Castle.Windsor.  Something to do with a change to the Castle.MicroKernel.Proxy.ProxyOptions.

One of the horn contributors EmmeKappa kindly created a new 2.1 descriptor for Castle.Windsor and updated the the WcfFacilitiy descriptor to the following. 

dependencies:
    dependency "castle.core" >> "Castle.Core"
    dependency "castle.windsor" >> 2.1 >> "Castle.DynamicProxy2"
    dependency "castle.windsor" >> 2.1 >> "Castle.MicroKernel"
    dependency "castle.windsor" >> 2.1 >> "Castle.Windsor


 
Many thanks to him for doing this.

The problem is that this does not help my scenario.  It would be fine if I was only using Windsor and the WcfIntegration facility but I am not, as you can see from my list of Castle bits I listed at the start of the post.

I can of course update all the descriptors with Windsor dependencies to point to the 2.1 Windsor descriptor but what if I want a trunk build? 

One of my original goals with horn is to get a trunk build without having to mess around with nant, svn, git, msbuild and the rest.  As the castle subprojects are now autonomous, I would have to get each subproject from subversion and build them individually, copying the output into each lib folder.  A job horn can do if all the descriptors are there.  The same job without horn is a serious pain and one that would be really off putting.

My fear is that Castle will turn into a contrived dependency maze with each subproject having different versions of other castle subprojects in their various lib folders.

I hope I am not speaking out of turn here but I really think Castle needs to ensure that the subprojects do not turn into a maze of castle dependencies, never mind throwing the rest of the .NET dependencies into the mix.  I have a feeling it has already started to go this way if care is not taken to ensure that strict versioning is adhered to.

It is obvious from the list of castle bits I detailed at the start of the post that I am a huge fan of castle but I am starting to think that updating the stack could be off putting for some users like myself. 

As for horn, I am really in a quandary of how to manage this as lots of horn descriptors reference the various castle bits.

The goal of horn is to have all you dependencies at the same level and just download and copy them into your lib folder.

Thoughts please

Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/

Michele Cantelli

unread,
Jan 20, 2010, 5:55:27 AM1/20/10
to HORN Development
Maybe the kkozmic solution posted on twitter (horn probes the new
dependency version, and if it doesn't not compile fall back to an
older version) could be a treatment for the symptom but if they
(castle committers) won't get a build in their CI which compile all
the stack they won't notice a breaking change and that is the problem.

Paul Cowan

unread,
Jan 20, 2010, 6:07:14 AM1/20/10
to horn-dev...@googlegroups.com
I think we discussed that solution in horn before, I need to have a dig about and discuss it there.

I guess where I am coming from and I am of course not a castle contributor  so it is very much my thoughts as a user, is that the castle pieces are linked together because I use various parts of the stack as I outlined in my post.

I need to ensure that the castle core binaries in WcfIntegration are the same binaries as are in Windsor etc. or all hell breaks loose.

I use a number of castle bits and I have to rely on castle to have the same versions of the castle binaries in the various lib folders.  I think this is not going to happen without checks in place and you get into a .dll hell scenario which we already have in a grand scale   in .net OSS as a whole.

As each project grows orthognally with breaking public interface changes then it becomes harder for me as a user to piece them back toghether and use them if I want to update to new versions or use the trunk.  The upshot being I can only use the versioned releases which may or may not fit together or I am back to mucking about in svn, nant and making code changes myself.

This is not an enjoyable experience.



Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2010/1/20 Michele Cantelli <emme...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "HORN Development" group.
To post to this group, send email to horn-dev...@googlegroups.com.
To unsubscribe from this group, send email to horn-developme...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/horn-development?hl=en.




Johannes Gustafsson

unread,
Jan 20, 2010, 7:09:55 AM1/20/10
to horn-dev...@googlegroups.com
I agree in most parts. However, IMHO, since we are trying to build several libs against the latest trunk, we, as users, should be prepared that it does not always compile. Trunk is usually bleeding edge after all. If I want guarantees that it will compile, I should use versioned branches instead. One of the big advantages of horn is just that, if some component breaks then it is quite easy for me to fall back to an earlier version of that component. 

Myself, I have a dependency similar to yours, with added trunk versions of nhibernate, nh.linq, FNH and so on. When the castle project split up i would probably have been forced to use their released binaries if horn had not existed. Now it is a breeze (or at least much simpler :-))

Paul Cowan

unread,
Jan 20, 2010, 7:17:36 AM1/20/10
to horn-dev...@googlegroups.com
The trunk as you stated is bleeding edge and I agree to a certain degree with what you say, although it would be nice if all the Castle trunk bits were at least aware of each other.

I still have concerns (maybe unjustifiably) that there is still scope for the VERSIONED projects to have conflicting dependencies in their lib folders which will cause problems.

There are no checks in place to ensure this does not happen.  I still think castle should be vaguely viewed as a whole as it is more usual to use different parts than just one subproject.

As I also stated, I am not a castle contributor and should perhaps mind my own business :-) but after a year or so of horn, I have seen how fragmented things are and how difficult it can be to pull it all together.

The situation I outlined with the WcfIntegration is a good example of the problem I am trying to explain.


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2010/1/20 Johannes Gustafsson <ved...@gmail.com>

Paul Cowan

unread,
Jan 20, 2010, 7:19:01 AM1/20/10
to horn-dev...@googlegroups.com
Also do not forget that bug fixes are applied to VERSIONED projects that requires a user to update their stack.



Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2010/1/20 Paul Cowan <dag...@scotalt.net>

Simone Busoli

unread,
Jan 20, 2010, 1:07:00 PM1/20/10
to horn-dev...@googlegroups.com
I mostly agree with you Paul, and my opinion is that having each project in the Castle stack always up to date with the latest build of the projects it depends on is the way to go. This could be accomplished by the CI process and one project would fall back to an older version of a dependency only in case of incompatibility, which I would expect not to occur very often.

Paul Cowan

unread,
Jan 21, 2010, 7:57:58 AM1/21/10
to horn-dev...@googlegroups.com
I totally agree with you Simone, the CI build is the place for this.

If the castle dependency map turns into the same as Rhino did then you will get problems.

I just get the impression that the OSS projects don't care about these things.


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2010/1/20 Simone Busoli <simone...@gmail.com>

Krzysztof Koźmic (2)

unread,
Jan 21, 2010, 7:59:05 AM1/21/10
to HORN Development
Problem with Castle is that it's pretty big set of cooperating but at
the same time to some degree independent projects.
Different parts move at different speed (as their maintainers/users
find time to contribute).

We are painfully aware of the fact that updating things that everyone
depends on, like Core means all other projects need to
update the reference which takes some time to propagate. Also

Solution I think would be nice and beneficial to both - Castle and
Horn projects is the following

- Horn would have to track "last compatible version" between projects,
and as new changes are committed in Castle, probe the new code
and try to build it and projects depending on it, to see if there were
any breaking changes introduced.

if there are none, than trunk is the last compatible version. If there
are breaking changes, Horn would not upgrade its packages, and use
the previous version of the dependency unless a next compatible
version appears.

Since Horn would now build the entire grid of dependencies it would be
wasteful not to take advantage of that. It would be great if Horn
could
collect and expose information about all breaking changes introduced
in one project that affect other projects. Better yet if it could do
that including
other projects, from outside of Castle.

When working on DynamicProxy, I used to check out Rhino Mocks and MOQ
from time to time, to see if I didn't introduce any regression bugs by
any chance.
If horn could do this automatically and notify me when such issue
occurs that would be huge.

cheers,
Krzysztof

> >> 2010/1/20 Johannes Gustafsson <vedk...@gmail.com>

> >>>> 2010/1/20 Michele Cantelli <emmeka...@gmail.com>

> ...
>
> read more »

Paul Cowan

unread,
Jan 21, 2010, 8:08:01 AM1/21/10
to horn-dev...@googlegroups.com
Hi Krysztof,

Thanks for the detailed answer.  To me this does indeed sound like the next evolution of making horn useful.

Reporting is something we are not doing for the web and we should collect this information during the build EVERYTHING process.

Being able to work back to the last compatible build sounds like a great idea and also fun to code!!


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2010/1/21 Krzysztof Koźmic (2) <krzy...@kozmic.pl>

Simone Busoli

unread,
Jan 21, 2010, 2:22:58 PM1/21/10
to horn-dev...@googlegroups.com
I like the idea too, although I'm not sold on the fact that it's something an external tool should provide. Of course if it does, then I'm fine :)

2010/1/21 Paul Cowan <dag...@scotalt.net>

Paul Cowan

unread,
Jan 21, 2010, 2:26:32 PM1/21/10
to horn-dev...@googlegroups.com
I know were you are coming from with that one Simone.

It should be the OSS project's concern to ensure you can maintain a dependency stack without outside help.

That of course will never happen.

As previously stated, it should be a standard part of the CI build process to copy dependencies into the various lib folders.

Maybe we could make horn to do that also perhaps?


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2010/1/21 Simone Busoli <simone...@gmail.com>

Simone Busoli

unread,
Jan 21, 2010, 2:43:37 PM1/21/10
to horn-dev...@googlegroups.com
Yes, horn could definitely provide that, the basis for the feature is already there if I'm not mistaken.

2010/1/21 Paul Cowan <dag...@scotalt.net>

Gauthier Segay

unread,
Jan 25, 2010, 4:04:33 PM1/25/10
to HORN Development
just to point that Roelof Blom just set a teamcity project building
all projects from their respective trunk

http://groups.google.com/group/castle-project-devel/browse_frm/thread/4e93e0e402d61f34

http://builds.castleproject.org/project.html?projectId=project36&tab=projectOverview

On Jan 21, 8:43 pm, Simone Busoli <simone.bus...@gmail.com> wrote:
> Yes, horn could definitely provide that, the basis for the feature is
> already there if I'm not mistaken.
>
> 2010/1/21 Paul Cowan <dag...@scotalt.net>
>
>
>
> > I know were you are coming from with that one Simone.
>
> > It should be the OSS project's concern to ensure you can maintain a
> > dependency stack without outside help.
>
> > That of course will never happen.
>
> > As previously stated, it should be a standard part of the CI build process
> > to copy dependencies into the various lib folders.
>
> > Maybe we could make horn to do that also perhaps?
>
> > Cheers
>
> > Paul Cowan
>
> > Cutting-Edge Solutions (Scotland)
>
> >http://thesoftwaresimpleton.blogspot.com/
>

> > 2010/1/21 Simone Busoli <simone.bus...@gmail.com>


>
> >>  I like the idea too, although I'm not sold on the fact that it's
> >> something an external tool should provide. Of course if it does, then I'm
> >> fine :)
>
> >> 2010/1/21 Paul Cowan <dag...@scotalt.net>
>
> >>> Hi Krysztof,
>
> >>> Thanks for the detailed answer.  To me this does indeed sound like the
> >>> next evolution of making horn useful.
>
> >>> Reporting is something we are not doing for the web and we should collect
> >>> this information during the build EVERYTHING process.
>
> >>> Being able to work back to the last compatible build sounds like a great
> >>> idea and also fun to code!!
>
> >>> Cheers
>
> >>> Paul Cowan
>
> >>> Cutting-Edge Solutions (Scotland)
>
> >>>http://thesoftwaresimpleton.blogspot.com/
>

> >>> 2010/1/21 Krzysztof Koźmic (2) <krzysz...@kozmic.pl>

> ...
>
> read more »

Paul Cowan

unread,
Jan 26, 2010, 4:21:15 AM1/26/10
to horn-dev...@googlegroups.com
I think that is a sensible approach.

As much as I love Castle, I have started to think recently that if I did not use Castle or Rhino then I would not have the same update problems for getting bug fixes or new features.

If I just used Nhibernate and StructureMap/Autofac on their own then I really could cut down on the dependency madness I experience.



Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



2010/1/25 Gauthier Segay <gauthie...@gmail.com>

Simone Busoli

unread,
Jan 26, 2010, 1:16:59 PM1/26/10
to horn-dev...@googlegroups.com
I think unifying some assemblies in the Castle stack is something planned, but you can always ping the team about this, and actually the recent split of the projects was something ideally already in this direction.

2010/1/26 Paul Cowan <dag...@scotalt.net>

Krzysztof Koźmic (2)

unread,
Jan 27, 2010, 8:39:27 AM1/27/10
to HORN Development
Yes, there are plans to do some merges of the assemblies.
Since no one really uses MicroKernel without Windsor, we plan to merge
Windsor/MicroKernel/Core/DynamicProxy (plus perhaps DictionaryAdapter)
into two assemblies.
Also logging facility and services are versioned together with these
projects now, which should also minimize potential clashes
porbability.

Krzysztof

On 26 Sty, 19:16, Simone Busoli <simone.bus...@gmail.com> wrote:
> I think unifying some assemblies in the Castle stack is something planned,
> but you can always ping the team about this, and actually the recent split
> of the projects was something ideally already in this direction.
>
> 2010/1/26 Paul Cowan <dag...@scotalt.net>
>
> > I think that is a sensible approach.
>
> > As much as I love Castle, I have started to think recently that if I did
> > not use Castle or Rhino then I would not have the same update problems for
> > getting bug fixes or new features.
>
> > If I just used Nhibernate and StructureMap/Autofac on their own then I
> > really could cut down on the dependency madness I experience.
>
> > Cheers
>
> > Paul Cowan
>
> > Cutting-Edge Solutions (Scotland)
>
> >http://thesoftwaresimpleton.blogspot.com/
>

> > 2010/1/25 Gauthier Segay <gauthier.se...@gmail.com>


>
> > just to point that Roelof Blom just set a teamcity project building
> >> all projects from their respective trunk
>

> >>http://groups.google.com/group/castle-project-devel/browse_frm/thread...
>
> >>http://builds.castleproject.org/project.html?projectId=project36&tab=...

> ...
>
> więcej »

tom

unread,
Feb 1, 2010, 3:30:08 PM2/1/10
to HORN Development
I like where this is going. I got scared that it was going to turn
into DLL hell if you wanted to use multiple parts of the castle
stack!

> ...
>
> read more >>

Paul Cowan

unread,
Feb 1, 2010, 4:36:04 PM2/1/10
to horn-dev...@googlegroups.com

Is anybody interested in taking on these tasks?

I don't have the time right now for various reasons but I can assist anyone who fancies a challenge.

Is anyone interested in this?

On Feb 1, 2010 8:30 PM, "tom" <tomm...@gmail.com> wrote:

I like where this is going.  I got scared that it was going to turn
into DLL hell if you wanted to use multiple parts of the castle
stack!

On Jan 27, 8:39 am, Krzysztof Koźmic (2) <krzysz...@kozmic.pl> wrote: > Yes, there are plans to do ...

> ...
>
> read more >>

-- You received this message because you are subscribed to the Google Groups "HORN Development" gr...

Johannes Gustafsson

unread,
Feb 1, 2010, 4:51:22 PM2/1/10
to horn-dev...@googlegroups.com
I don't seem to have followed this thread very well, but what exactly are we talking about that needs to be done in horn? ILMerge:ing assemblies?

/Johannes

--

Simone Busoli

unread,
Feb 1, 2010, 8:53:47 PM2/1/10
to horn-dev...@googlegroups.com
WRT Castle, I think building the entire stack with the latest non failing revisions of all the various pieces.

Paul Cowan

unread,
Feb 2, 2010, 1:56:59 AM2/2/10
to horn-dev...@googlegroups.com
Hi,

I do not mean building with ILmerge.

I mean horn's ability to revert back to the last build that did not break in the event of  a breaking package.


Cheers

Paul Cowan

Cutting-Edge Solutions (Scotland)

http://thesoftwaresimpleton.blogspot.com/



Reply all
Reply to author
Forward
0 new messages