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?

6 Years
Discussion Span
Last Post by zachattack05

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...).


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.

This question has already been answered. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.