http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660My response: [blog.jordanterrell.com/.../...-Libraries-Dead.aspx](http://blog.jordanterrell.com/post/CommonUtility-Libraries-Dead.aspx)http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment22http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment22Mon, 11 May 2009 16:54:58 GMTSeeing this post brought to mind this post by Jay Fields: [blog.jayfields.com/2009/03/kill-your-darlings.html](http://blog.jayfields.com/2009/03/kill-your-darlings.html), which in turn riffs on Michael Feathers: [www.artima.com/weblogs/viewpost.jsp?thread=8826](http://www.artima.com/weblogs/viewpost.jsp?thread=8826) Seems to me at least part of what we're talking about here is useful shared tools which keep getting extended as the userbase (and hence requirements) grow. Feature creep in the context of open source? http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment21http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment21Wed, 06 May 2009 08:36:51 GMTI don't think "common" libraries are bad. Sure you could break them up into assemblies with related functionality, but they you end up with lots of interdependent referencing. (To reference A you need to reference B & C & D because parameters from A or return types/exception definitions are defined in a different assembly now.) In any case I've heard it argued that fewer, larger assemblies utilizing meaningful namespace separation are better than many, smaller ones with only one or a few namespaces. I've actually recently been pushing more functionality into "common" type assemblies. Though this is also because I'm a composition nut. My common library is one of my best tested blocks of code. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment20http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment20Fri, 01 May 2009 00:27:08 GMT@Rafal I typically put my Scheme interpreter from college into all my projects just to throw guys off =) http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment19http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment19Thu, 30 Apr 2009 22:00:38 GMTRafal, Most people steal it from NHibernate http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment18http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment18Thu, 30 Apr 2009 09:08:22 GMTOk, folks. Where to put GuidCombGenerator? Almost every project I have seen recently contains this class...There is a theory that every software project evolves until it contains a crippled email client and a lisp interpreter - maybe we should add a guid generator to that list... http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment17http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment17Thu, 30 Apr 2009 08:27:26 GMTIt is only a matter of componentization. In the Bryan's solution.. Rhino.Commons.Collections Rhino.Commons.Configuration Rhino.Commons.Threading.ThreadPool etc. the ONLY think that matter is oi make sure that each of these namespace are not statically dependent on each other, meaning you can take one of these, put it in its own project and recompile it immediately. Now you might have dependencies between for instance, # Provide nicer semantics for using MultiCriteria with NHibernate # Provide Future queries support externally to NHibernate because they must both rely in the same Rhino.Commons.NHibernate component. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment16http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment16Thu, 30 Apr 2009 07:20:06 GMTOren, Some of these things should be moved over to more appropriate places - like the Windsor DSL. Shouldn't that be a contribution to the Castle Project? http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment15http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment15Thu, 30 Apr 2009 06:33:11 GMT@Rafal Please, please do not do that... What happens then when you need to fix MyFooSnippet which has been used in 72 different projects? Just because someone (Ayende) has decided to use it as a catchall (it MIGHT be reusable one day so I'll put it in common) doesnt mean that common/util libraries are bad. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment14http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment14Thu, 30 Apr 2009 04:07:14 GMTIt seems that Util dll's are often a fear of having many projects in your solution. I usually create separate projects for each unrelated piece of "common" functionality. This also helps at compile time, since a change in a base "common" lib only forces the dependent projects to recompile Generally, i take the next step and move the interfaces of common pieces into separate interface dll's so that code changes that don't touch the contract don't require any recompile of the dependent assemblies. It's basically taking the IoC pattern to the assembly level. The Graph Add-in for Reflector ( [reflectoraddins.codeplex.com/.../View.aspx](http://reflectoraddins.codeplex.com/Wiki/View.aspx?title=Graph) ) is a great tool for seeing how deep your dependencies go and help you flatten out those hierarchies. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment13http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment13Wed, 29 Apr 2009 17:43:41 GMTI was ready to disagree based on the opening, but then I read the list of features in Rhino.Commons. That's quite a diverse magic bag you've got there. You are right. Cohesion does matter. I tend to build smaller magic bags which are organized by topic, and can be used separately. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment12http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment12Wed, 29 Apr 2009 16:52:32 GMTI think that rhino.commons also have a lot of infrastructure and is not compatible with this: [ayende.com/.../Infrastructure-Ignorance.aspx](http://ayende.com/Blog/archive/2008/02/12/Infrastructure-Ignorance.aspx) Look at the nhrepository. I think the code is more reusable than the entire library. "The sum of its parts is more than the whole." http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment11http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment11Wed, 29 Apr 2009 15:13:32 GMTI have to agree with Bryan. The common library that I've written at work is packaged this way. There are five components: Common, Security, Logging, Reporting, and Web. It works quite well if I do say so myself. I'll agree with you though that having one bin for all your stuff that you couldn't be bothered to find the proper place for isn't a good idea. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment10http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment10Wed, 29 Apr 2009 13:37:39 GMTSounds to me like a packaging and organization problem. If Rhino.Commons is too big, now, you just need to break it up. Rhino.Commons.Collections Rhino.Commons.Configuration Rhino.Commons.Threading.ThreadPool etc. Then you can still provide "Rhino.Commons" as the uber zip archive of all the DLLs. Seems like a simple solution to me. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment9http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment9Wed, 29 Apr 2009 13:10:52 GMT@configurator the .NET Framework isn't in one assembly, its arranged by funciton http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment8http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment8Wed, 29 Apr 2009 13:01:38 GMTWhat about the .Net framework? It's a big collection of unrelated stuff, isn't it? http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment7http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment7Wed, 29 Apr 2009 12:26:39 GMTOur common framework classes are grouped into 'projects' around function, which is usually also what they have dependencies on, i.e. ORM, WCF, etc. All our provider classes adhere to well-defined interfaces located in a different 'interface assembly' that have no dependencies. We also provide an ILMerge of all our common implementation assemblies and interface assemblies into 2 distributed assemblies (interface and implementation) for convenience. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment6http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment6Wed, 29 Apr 2009 11:58:38 GMTWe tend to split utility functions in a project into a single location, later on we may refactor into more generalized areas.. we also follow a rule of re-use, given we think we've found a pattern that has existed in a few projects, we work to develop a more solid general 'product', if that product works we will 'brand' it under our company name.. The point is that we've pretty well isolated a pattern and created a product which is easy to name because its specific to a solution.. then it basically just gets its own namespace somewhere in our stack. This way our reusable code base tends to stay clean and well versioned. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment5http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment5Wed, 29 Apr 2009 10:43:04 GMTtvbusy, FYI, Rhino Security doesn't have a dependency on Active Record or Boo DSL The Windsor dependency is pretty easy to abstract (although you would need to create a registry for it for StructureMap). As for .Net 3.5, we aren't using any features from there, but we are using some syntax, again, that is pretty easy to resolve. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment4http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment4Wed, 29 Apr 2009 10:03:51 GMTJust for clarification, my project does use NHibernate and I does use ActiveRecord in another project. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment3http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment3Wed, 29 Apr 2009 09:52:24 GMTCoupling is exactly the reason why I could not use Rhino Security for my project. My project (.NET 2.0) has already used StructureMap for IoC, but if I want to use Rhino Security, I have to use Windsor, *plus* Boo DSL, *plus* dependency on .NET 3.5, *plus* ActiveRecord. They're too much for just a security provider. I did try extracting Rhino Security out of above mentioned dependencies, but the efforts was way too high compared to rolling out my own. http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment2http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment2Wed, 29 Apr 2009 09:51:02 GMTConvert it to a bag of more or less useful code snippets for various occasions - just copy & paste. Every project has its 'utils/tools/commons/shareds' and has to have one. Where else to put various helpers, wrappers, containers or adapters? http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment1http://ayende.com/3986/let-us-burn-all-those-pesky-util-common-libraries#comment1Wed, 29 Apr 2009 09:30:45 GMT