Q:

Best practice when creating reusable corporate namespace

Alright, this has been on my mind for a while now. I'm in the process of creating a reusable corporate namespace(class library) for all common middle-tier objects. This assembly can then be referenced by any of our developers during the development phase of their project. Here's my question. Is it more acceptable to create a single assembly which consists of all our middle-tier logic or to break this functionality up into smaller assemblies?
Example: Single Assembly(namespace examples)
System
System.IO
System.IO.RegEx
System.Net
System.Net.Mail
System.Security
System.Web - AssemblyFull.dll
Example: Multiple Assemblies
System.IO
System.IO.Reg - Compiles to AssemblyIO.dll
System.Net
System.Net - Compiles to AssemblyNet.dll
In the past I've done this using both methods but I'm wondering what everyone else does and why? I'm not looking for any code examples, I just want to know what other developers have doing?
Thanks in advance.

A:

As a general rule, I use to separate assemblies if they are not explicit coupled. For example if you have a low level Networking API, and other API for FTP related operations, probably the later depends upon the former; but for the API user, your developers; there is no need to have both in a single assembly; maybe one project does not require the FTP API, so they only need to include the core "Net" assembly. You can separate APIs in order to be the more atomic as possible and avoid developers to include a big assembly when their will use only a small part of it.
The down side of this approach is that if the developer needs the FTP assembly they also need to include the Net one; so you have to find a way to manage those dependencies that reduces the complexity for developers. I use Maven (from Apache) when doing Java applications but by this date I do not know a good maven-like alternative for .NET.
But if your are building a few APIs for your company, with a Wiki site or other light weigh documentation tool you can address this problem.

