OneTrueError - Automated exception handling

Request for comments: Merging libraries

I currently have a number of libraries which I develop (at github). Most of them are small (less than 50kb) and I’m thinking about merging them into one library instead.

What I mean is that I will add them into a single github project.

Why?

To me, choice is important. You can always choose to use your own favorite container instead of mine for any of the libraries. However, I also do like to make things easy. For instance, if I want to create a dead easy setup for Griffin.Decoupled I have to create several small nuget packages and make sure that different versions of all libraries work together.

I’m developing more and more features which are cross cutting between libraries, and it is increasingly difficult to manage the differences.

How?

I would join all projects which has no other dependencies than .NET into a single assembly (and therefore only namespaced project). The assembly would probably be about 200kb. All projects that got external dependencies would be named after their dependency. For instance “Griffin.Framework.RavenDb”

You will still of course be able to combine different libraries with other external libraries (as all interfaces will still be there).

Request for comments

What do you think? Do you mind to get a 200kb assembly instead of a 44kb assembly if you for instance only want to use Griffin.Networking or Griffin.Container?

This entry was posted in Uncategorized. Bookmark the permalink.
  • Steven

    I would opt for keeping them ‘decoupled’. Especially a container should be a different package.

  • http://twitter.com/fidelio_blogger Amir Hussein

    What is the situation on their inter-dependencies? Because to me, if They do no have any dependencies among each other, there is no need for them to be in the same assembly.

    • JonasGauffin

      Examples:

      I’m building a RPC client for Griffin.Networking. To make it powerful I support containers and logging. But since those are in different assemblies I would have to create Griffin.Networking.Rpc.Logging, Griffin.Networking.Container, And if Griffin.Container also were to support logging I also have to create Griffin.Container.Logging.

      Griffin.Decoupled heavily relies of containers. So if I want to support mine I have to create a Griffin.Decoupled.Container package again. And if I want to create distributed queries I have to have dependencies on Griffin.Networking, Griffin.Networking.Rpc and Griffin.Networking.Logging.