Building libraries for reuse across multiple projects

[zachattack05]

Greets again!

I am working on a project and have some controls that I have created, and even some full namespaces that I think would be very useful to other projects I am working on and possibly future ones.

I'm considering pulling the code for those namespaces/controls out of the project, creating a library and just linking the project to the library.

The question I have is at what point does it get excessive? I know this probably sounds like a subjective question, but I am talking mostly about objectively, the performance, the wasted space of delivering a dll to end users where certain controls may or may not be utilized?

For example, if my library has a namespace called .Windows.Forms the same as the MS System namespace has, and I include in that namespace, objects, classes etc. that can be used on forms like textboxes that perform certain validation, or more complex controls/classes, at what point is it a bad idea to include in a project a library where only one or two of potentially hundreds of classes/controls are used?

Is there much of a performance change (regardless of code quality) in a 300K library compared to a 3MB library?

For efficiency in development, deployment and maintenance, I would think a single library with many classes is preferred rather than many small ones. Obviously if they serve different purposes that's one thing, but throwing an entire namespace into a library seems like it makes sense to me. A library called .Windows.Forms instead of 2 called .Windows.Forms.Textboxes and .Windows.Forms.Buttons etc...

Any thoughts?

[thines01]

The optimizer can handle most of the problem of large libraries (loading or not loading). I'm sure there is some minor performance impact by referencing a larger file of potentially unused methods and resources.

Another issue is the concept of giving away all of your goodies every time you deploy.

I have LOTS of DLLs and only reference the ones I need. Most of them are as generic as I can make them, so it won't matter if I'm using a console app, win form, asp.net or other.

I usually let USE dictate what needs to be a library. I can feel when something is going to be reused and immediately create another project with that as the class library.

Attempting to pre-package not-yet-useful code into a library will eventually be an inefficient use of time. It will provide the potential for you to re-write a class accidentally and remember you already wrote it and then want to replace the old one with the new one and now your DLL needs to be re-deployed to every program you've ever written ;) (...you know what I mean...).

[zachattack05]

Wow that's actually a very good point that I never considered!

I think the concern about rewriting a class that has already been written is a valid point, but could happen with any class, even if a dll already exists for it.

I did think about the problem of giving stuff away. While I would say 90% of the people out there who purchase software, aren't even aware of dlls, or if they are, have no concept of what they do. It's the 10% that know enough to fiddle around and possibly get your source only to find it was a present full of even more than they expected. I'd like to prevent that as much as possible, without losing my mind, but it is a very good point.

I was on the fence as it is, I think I might stick to that idea of creating simpler dlls instead of a huge catch-all collection.