Class library / shared library development within company?

Are there any guidelines / best practices on developing a class lib开发者_开发问答rary (custom internal 'enterprise library') or shared source project or solution with multiple projects perhaps, within a small to medium sized webdevelopment company (~50 employees)?

Currently there is one project which includes all 'reusable' code and can be included in new projects. The project is not 'heavy' by far, but the code is not logically connected either, it's just a big pile of previously created functionality. Which questions need to be asked to decide if this is a good approach?

It sounds like you have large-ish assembly that has all of the shared functionality in it (correct me if I'm wrong).

As with most things there are benefits and negatives associated with this approach which depend on your needs.

In the ("outdated" but probably still relevant) article Improving Managed Code Performance it is actually recommended to "Prefer Single Large Assemblies Rather Than Multiple Smaller Assemblies". I'm not sure if any performance impacts would be noticeable. If they were noticeable, I would think it would only be at startup.

Even if all your code is in one assembly, for ease of use, I would recommend to logically partition functional areas into separate namespaces. Your use of the word "pile" seems to imply that this might not be the case.

On the positive side:

• Adding a reference to a single assembly is easy to do
• Deployments could be easier since there is only one assembly to deploy (harder to mess up?)
• Potential performance improvements

On the negative side:

• If 90% of your users only use 5% of the actual functionality then it might not be "worth" loading the entire assembly
• A single assembly could make enforcing architectural/design standards harder. e.g. If the UI layer should not talk directly to the data layer it probably doesn't make sense to expose shared data access functionality. A single assembly could making noticing this kind of "error" easier. "Why are you reference the data access assembly from the UI?"

As I mentioned before, I think more important than the actual packaging of the assembly is the logical grouping of functionality within that assembly. In your Enterprise.dll assembly I would expect to see a few namespaces that organized the functionality. e.g. Enterprise.Logging, Enterprise.Caching, Enterprise.Validation, Enterprise.DataAccess, Enterprise.Security etc.

Guidelines/Best Practices on developing class libraries: http://msdn.microsoft.com/en-us/library/ms229042.aspx

Can you clarify? What exactly do you mean when you say "...it's just a big pile of previously created functionality."?