http://blogs.clariusconsulting.net/kzu

Daniel Cazzulino's Blog

Go Back to
kzu′s Latest post

Introducing NETFx, or the end of Common.dll and Helpers.dll

From the project home page:

What

Lightweight NuGet packages with reusable source code extending core .NET functionality, typically in self-contained source files added to your projects as internal classes that can be easily kept up-to-date with NuGet.

Why

Who doesn’t have an ever growing and ever less cohesive miscellaneous collection of helpers, extension methods and utility classes in the usual “Common.dll”? Well, the problem is that there’s really no good place for all that baggage: do we split them by actual behavioral area and create “proper” projects for them?

In most cases, that’s totally overkill and you end up in short time with the same pile of assorted files as you try to avoid setting up an entire new project to contain just a couple cohesive classes.

But, it turns out that in the vast majority of cases, those helpers are just meant for internal consumption by the actual important parts of your code. In many cases, they are just little improvements and supplements over the base class libraries, such as adding missing overloads via extension methods, adding factory methods for otherwise convoluted object initialization, etc. It’s almost inevitable that as the .NET framework and its languages evolve, existing APIs will start to look dated and lacking (i.e. lack of generics from v1 APIs, or eventually lack of async-friendly Task-based APIs once C# 5 is with us, etc.).

But with the advent of NuGet there’s a new way to maintain, evolve and share those useful little helpers: just make them content files in a NuGet package!

And thus NETFx was born: a repository of the source and accompanying unit tests for all those helpers, neatly organized (under the Extensions folder in the source tree, by target namespace being extended), deployed exclusively using NuGet, and licensed entirely under BSD for everyone to use and contribute.

How

You install NETFx nugets via the Add Library Package Reference dialog (this is easiest, since the individual package ids are fairly long and organized by extended namespace):

Note that you don’t get a single monolithic gigantic “NETFx Package”, but rather you get to pick precisely what you need and nothing more.

From the Package Manager Console, you can also just type install-package netfx-[TAB] and see a list of NETFx packages:

Or even filter by area by entering a fragment of the namespace:

And unlike most nugets, what you always get from NETFx is the actual source, as internal classes (the point of helpers!) that you build together with your own source. Need to debug it? Found a bug? No problem! The source is right *there* for you to see, patch or whatever:

 

And every NETFx has its own place for Source + Unit Tests so that anyone can read the tests and see how to use a class, contribute patches and improvements for existing ones, or even send a pull request for a new one.

Publishing new NETFx nugets has been made so straightforward that a new one can pop-up in http://nuget.org in about 15’ (time it takes to write an extension method and its unit tests).

The list is already fairly extensive, and growing all the time.

 

Read our documentation to get involved and contribute fixes or new netfx extensions! We even have a project template to make the entire process enjoyable Smile

 

This project is sponsored by Clarius Labs.

Comments

6 Comments

  1. Woah dude. My hero. Something in my gut said something like this was possible, I just got lazy in trying to implement it (plus I’ve had no real need. NuGet is still in a sandbox for me). NuGet is morphing into something well above just a dependency resolver to me and I’m really glad this type of behavior can be done.

    If I haven’t said it before, or enough, I’m extremely grateful for what you contribute. I use Funq and Moq off the top of my head and despite whatever friction I have it tends to be down to user error over something missing. Thanks again for NetFx too because if I ever wanted to follow in similar footsteps for internal company or personal projects I have a perfect starting point. Awesome.

  2. Thanks a bunch Jeremy!

    Funq with MEF-attributes convention is coming, btw ;) . And via a nuget, of course ;)

  3. Thanks, Daniel! Awesome.

  4. [...] Introducing NETFx, or the end of Common.dll and Helpers.dll – Daniel Cazzulino’s Blog. Share and [...]

  5. kzu,

    Great work. The concept is brilliant, and helps solves a long time challenge.

    In practice, there needs to be some good tooling to support this philosophy and mechanism (in VS for example) that makes it scale. Something that helps a developer on an open source project tell the difference between a ‘native’ source file in their codebase that belongs to their project (i.e. governed by the coding policies in the project), and those ‘imported’ files from another project like NetFx.
    Why? because source imported from another project is more than likely not going to comply to this projects native coding standard, and therefore should not be treated as if it should. It should be treated as ‘ignored’ by policies and tools that manage such things.
    It should be marked in a way that is eveident to a developer that they should not alter the code, because it could get updated at anytime in the source project, and by the nuget. Unless that is the desired behavior of course.
    So, there would be some visible indicator that the code would either continue to be ‘imported’ by its nuget or from this point forward ‘cloned and owned’ as ‘native’ code on the project.
    Ideally, the tooling would lock the file from editing for the developer (or some such safeguard), and be marked in some way that it does not comply with the projects coding standards, and tells tools like Resharper to ignore it.

    Further, it could be explicitly unlocked, and detached from its nuget, and evolved by the project in whatever direction they choose as ‘native’.

    Such tooling would be invaluable to helping scale this concept across large projects.

  6. [...] so I started doing just that for my own stuff, and thus MSBuilderwas born. It is sort of like NetFxbut for MSBuild rather than .NET code. It may still suffer from that project’s Achilles [...]