Everyone who's doing .NET 3.5 development these days will likely run into the same problem I ran into this morning: your set of extension methods grows beyond the level of a single file and you need to group them into separate sets of files or worse: you discover you have several distinct projects which all have extension methods and it's better to group them into a single library.
So I started VS.NET 2008 and began with a new solution and a new class library project. Right at the spot when I was thinking how to name the darn thing (you must know I'm very good at cooking up catchy names 
), I realized it might perhaps be possible that someone else has had that same idea and already started such a library. It would be useless to have two extension method libraries for the BCL, so I went to CodePlex and searched for Extension Methods
The query returned 56 projects 
! Not all of them BCL extension methods, but all of them more or less libraries with extension methods. That's simply too much, people. The fragmentation shows: most of them are hardly used, downloaded perhaps 50-100 times. This is a bit sad, because some contain valuable extension methods, though to find these is a bit of a struggle: they're often buried in piles of useless filler methods or rewrites of existing extension methods. Besides that, it's still not that convenient to have to reference a group of libraries to have them all at your disposal.
For our own code, it's best if we have all BCL related extension methods into a single library so we have to reference just a single class library and I think that's true for most of you out there. Still, some of my extension methods aren't in any of the libs out there, though I'm undecided to which library to give them to and use that one: I don't want to base our code on a library which is perhaps already dead, and I definitely don't want to use a library which has a lot of code which is really redundant (e.g. it's already in the BCL) or silly or very project (but not my project) specific.
It's tempting to just dump the code on codeplex and be done with it, though in general that's not going to bring the .NET community forward: more fragmentation is not going to lead to more usage of the libraries already out there. However, not doing anything isn't good either: I'm sure a lot of developers out there have written the same RaiseEvent extension methods as I have done and have perhaps a few handy helpers which could be a valuable tool in everyone's toolbox, like the better DataRow.Field<T>(name) I wrote this morning so I don't get cast exceptions anymore. Having these methods grouped into a single library which is open source and free (i.e. uses a flexible license so no GPL-ed stuff) is what the community needs, if we all don't want to drown in extension method libraries.
Anyone out there who has thought about this already and has a solution for this? If so, please post in the comments below. In the meantime I'll group my extension methods in a separate lib so if nothing comes out of this, it will be project 57 .