- WTF twitter.com/realdonaldtrum… 10 hours ago
- Nice I love D3! gag.gl/eK0juj 22 hours ago
- RT @blackgirltech: If you're a Black woman & want to learn how to code but need some financial help, you should apply for the https://t.co/… 1 day ago
- Louie is growing so fast! https://t.co/hfvOqScGp3 1 day ago
- RT @vibronet: Open standards should be table stakes for everyone - but won’t be enough to save you from vendor lock-in https://t.co/TbMebtG… 1 day ago
Using TeamCity to Maintain a Stack of OSS Tools
September 9, 2010Posted by on
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.