Using TeamCity to Maintain a Stack of OSS Tools

One of the more difficult problems with using open source libraries in the .NET space is the incestuous nature of the .NET open source community. NHibernate has a dependency on Castle.Windsor. Castle.MonoRail has a dependency on NHibernate and Castle.Windsor. Fluent NHibernate has a dependency on NHibernate. TopShelf has a dependency on Common.ServiceLocator which if you are using the Castle stack adds a dependency for you on the Windsor provider for Common.ServiceLocator. And rarely do all projects have a dependency on the same version of the assembly you happen to have.

It leads to a serious case of DLL hell and honestly prolly scares off the average .NET developer. Tracking down dependency chains is not a great way to deliver value to your customer. Most developers I know end up maintaining their own builds of their external dependencies based on the trunk versions. We don’t want to wait around for Oren to update Raven to use the latest Castle.Windsor so we can take advantage of that spiffy new CollectionResolver baby!

But I am here to let you know that all is not lost. With a little elbow grease and some planning and forethought, you can overcome the problem. This screen cast show a way to tackle the problem. Bake your third party libraries into your CI process and be happy.