Splitting assemblies - finding the balance (avoiding overkill)

Posted by M.A. Hanin on Stack Overflow See other posts from Stack Overflow or by M.A. Hanin
Published on 2010-03-25T17:38:59Z Indexed on 2010/03/25 17:43 UTC
Read the original article Hit count: 438

I'm writing a wide component infrastructure, to be used in my projects. Since not all projects will require every component created, I've been thinking of splitting the component into discrete assemblies, so that every application developed will only be deployed with the required assemblies.

I assume that creating an assembly has some storage overhead (the assembly's code, wrapping whatever is inside). Therefore, there must be some limit to the advantage gained by splitting an assembly - a certain point where splitting the assembly is worse than keeping it united (storage-wise and performance-wise).

Now, here is the question: how do I know when splitting an assembly is an overkill?

P.S I guess there are other overheads to assembly splitting, aside from the storage overhead. If anyone can point out these overheads, it would be much appreciated.

© Stack Overflow or respective owner

Related posts about .NET

Related posts about best-practices