from el in world.ExtensionMethodsLibraries group el by el.Method into g select g;

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 .

20 Comments

  • Interesting I too just had a look and am suprised there is not 1 library that is 1 big 'Swiss' army knife of extension methods with 700 tools and a toothpick.

    What is your interest in beginning one? I would be quite interested in beginning System.SwissArmy :P...


    Cheers
    Stefan

  • I decided I liked this too much and have created yet another codeplex project :)

    http://www.codeplex.com/systemdotswissarmy

    Will think of ideas for this but I was taken by the name and had to do it.

    Any interest Frans?

    Cheers
    Stefan

  • Maybe Mono.Rocks could be the basis for the One True Extension Methods Library?

  • @Stefan: heh :) Well, the point of my post is not to have yet another 'this code is handy' library, which will eventually always grow into a library with datastructures and algorithms, I already have one of those (not (yet) released).

    The thing with an extension method library (so just the extension methods) is that it's often very lightweight and you therefore don't have reference issues nor clashing types.

    @commenter: I had never heard of Mono.Rocks, looking into the code of it, it looks like a lot of the code is already in the BCL of .NET: in linq to objects.

    that's the problem with lots of these libraries: they have some gems and the rest is really redundant. I saw in my code I had that too btw: I had a 'Delimit' extension method for IEnumerable(Of string), and yesterday I discovered String.Join so I could remove that one.

  • Frans,

    Very good points there I sometimes get a tad carried away :P.


    Cheers
    Stefan

  • @stefan: heh :) Actually, your post this morning about extension methods made me think about it in the first place, so don't stop getting carried away! ;)

  • Heh cool cheers :), I guess I will keep with my idea for now I have been wanting to start and run an OSS project for a while so this is something to do even if it adds library #999.

    Also I will have movement on the competition shortly I think this will be pretty exciting and should bring some interesting things out of the woodwork.


    Cheers
    Stefan

  • It's true, Frans is bad at naming things.

    LLBLGenPro? Template Studio? Aglaia? Come on!

  • I havent looked at the development version, but the release of Mono Rocks doesnt have much in it.

    It seems unlikely that it's mostly re-implementing stuff in System.Linq though. Mono includes a Linq implementation, so it would be unusual for the Mono guys to copy some bits and call it Mono.Rocks. In fact, of the 4 classes in the release of Mono.Rocks, none of them re-implement LINQ to Objects functionality.

  • @commenter: I looked at the code in SVN, and it has code which is similar to differently named IEnumerable methods. The code in SVN has much more methods than the list on the website.

  • Not exactly a library, but Fons Sonnemans has a public collection of extension methods at www.extensionmethod.net.

  • I personally don't believe in a single 'Swiss army knife' library. In most cases I think it's good enough to create an internal namespace with a few extension methods within your project and add extension methods when needed. Having many extension methods in your code isn't really helping IMO. For example, my mind is always scanning for NullReferenceExceptions, and those extension methods increase my brain’s working set. But maybe that's just me, and am I just paranoid :-)

    But I’m not against extension methods. And to prove it, it’s time to plug my own extension method library on codeplex :-)

    http://www.codeplex.com/conditions

  • > like the better DataRow.Field(name) I wrote this morning so I don't get cast exceptions anymore.

    I believe this is part of Linq to DataSet :-)

    Mmmmmm sweet irony!

  • @Bryan: yes .Field is part of Linq to DataSets, but it has a nasty side effect: if the value is a short for example, and you do:
    int value = row.Field("ORDINAL_POSITION");
    it crashes with a specified cast not valid error. This is particularly annoying because in the case where I use it, meta-data retrieval from the DB, so I have to use datatables etc., particular views differ between for example SQLServer 2000 and SQLserver 2005+ (in 2000 it's a short value, in 2005+ it's an int).

    So I needed a .Field (which I dubbed .Value()) which wouldn't crash but provided the same feature as .Field ;). So I did know .Field was there, it's just that it didn't work for the situation I was using it in, so a better extension method was required. ;)

  • Why not 1 extension methods project with multiple assemblies and mimic the layout of the assemblies that the extension methods are for?

    e.g. if the project is called OpenExtensions then all extension methods for string would live in OpenExtensions.System and in the OpenExtensions.System.dll, whereas all extension methods for DataRow would live in OpenExtensions.System.Data and in the OpenExtensions.System.Data.dll.

    This would provide 1 place to collect extension methods, a logical mechanism for finding ones appropriate to your needs and a simple distribution strategy.

  • @Neal: that will result in a lot of extension methods in OpenExtensions.mscorlib.dll, as most classes extended live there. I do like the namespace separation though. I think the physical dll separation will perhaps be a bit off, but indeed if you don't follow MS' dll separation but strictly on namespace it might be a nice separation technique, except perhaps for the drawback that if you have a wide variety of extension methods, you'll end up referencing a lot of different dlls again...


  • Thanks for the compliment Frans.

    Conditions is released under the LGPL license. Is this license open enough in your opinion, or do you advice an another license?

  • @Steven:
    For libraries, anything other than GPL is IMHO OK. GPL for libraries is not really useful as it forces users to open up their own code. LGPL doesn't suffer from that so it's good :). One thing you have to decide for yourself is what should a user of your code be able to do without you getting upset ;). For example, the LGPL forces people who make changes to your code to open these changes if they distribute the changes to someone. A BSD2 or similar license doesn't have that. It could be a valuable thing to have in the license to have all changes to the code be opened up as open source as well, but on the other hand, it could hurt acceptance.

    Though considering the fact that the # of downloads of class libraries from codeplex is shockingly low in most cases, I wouldn't be that worried about that last remark.

  • The OpenExtensions wiki where people can publish their one off extension methods and a couple of tests. Users could search the site and select the methods they want and get them into their projects either compiled as a dll or raw source with tests.

    It would make for a good VS plugin too.

    Eventually the most useful and best methods would rise to the top thus allowing for a community driven release of some kind.


  • As the founder of Umbrella (www.codeplex.com/umbrella), the whole point of Umbrella is to allow a central repository of those types of helpers. There's is a bunch of them already, we have many contributors and have given ourselves a structure to build on. Other extension library contributors have already started to merge their existing code into Umbrella, so feel free to contact us on CodePlex so we add you as contributors.

Comments have been disabled for this content.