"Global" Class Library: Best Practices?

[Graham Charles]

I've got several generic "library" routines that are used by many of my
controls & applications (things like string manipulation, generic error
handling, an "about" box generator, etc.). As I transition my apps from
VB6 to VB.NET, I'm curious about the best, most efficient way to
include those in my application. Here's what I'm considering:

1. My gut reaction is to compile these routines into separate class
libraries (AIID.SplashForm.dll, for example), and reference them from
whichever apps need them.

2. I could also include the source code right into my apps, using
SourceSafe for versioning.

Option 1 seems like it would be better, since only one version of each
set of shred library code would be loaded, no matter how many of my
apps are running. However, Option 2 might offer better performance (?),
since the code is compiled together. Or maybe that's my VB6 prejudice
coming through -- is there a performance hit in VB.NET for calling into
external DLLs?

Thanks for any advice.

 

[Graham Charles]

As a follow up, assuming that I'm creating separate class libraries,
should I err on the side of fewer or more libraries? In other words,
let's say I've got ten different "custom" dialog box classes (an about
box, a timed message box, a localized password box, etc.). Do I compile
them all together (into "Dialogs.dll", for example), or separately
("Dialogs.About.dll", "Dialogs.Timed.dll", etc.)? Not every app will
use every one, of course. But with a strategy of dividing the DLLs into
very discrete uses, I could quickly get 30 or 40 dependencies for each
application.

I realize this is a philosophical question! Just curious if there's a
"best practice."

 

[Lee]

I also have a bunch of 1) utility functions; 2) an error-handler class;
3) specialized collection classes. The items in (1) I put into a Module
(since they would be Shared methods anyway; the other items are in
their own classes. I put the whole shebang into its own DLL. BTW, this
is very similar to what I did with these in VB6.

 

[Guest]

I suspect you will be happier in the end if you include these dll's as
projects in your solutions (assuming they are in the same language). I've
had trouble including just the dll's as when I change one of them, it
sometimes gives me trouble compiling the solutions that use them (I did fix
this though by setting the assembly version of the dll's to a set value
instead of the *.

 

[Jay B. Harlow [MVP - Outlook]]

| I realize this is a philosophical question! Just curious if there's a
| "best practice."
I would go with what is "manageable".

Having too many assemblies quickly becomes hard to manage, as you are always
searching for which assembly to reference. Plus loading individual
assemblies does "cost". Having to many assemblies may also lead to hard to
resolve interdependencies & possibly circular dependencies (assembly1 needs
assembly2, assembly2 needs assembly3, assembly3 needs assembly1).

Having too few assemblies also quickly becomes hard to manage, as you may be
needing to recompile a number of your applications to make a simple change.
Plus loading a single assembly with "excessive" meta data also "costs".

Generally I would group the types into logical assemblies, so for example,
rather then having 40 dependencies, I would have 5 to 10 dependencies,
depending of course on what the various types are...

I would put all the common UI in a "Common.UI.dll". I would put all my
"framework" in a Framework.dll, common utilities, I would put in a
Common.utility.dll and so on.

Unfortunately I don't have my links handy on the matter.

--
Hope this helps
Jay [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net


| As a follow up, assuming that I'm creating separate class libraries,
| should I err on the side of fewer or more libraries? In other words,
| let's say I've got ten different "custom" dialog box classes (an about
| box, a timed message box, a localized password box, etc.). Do I compile
| them all together (into "Dialogs.dll", for example), or separately
| ("Dialogs.About.dll", "Dialogs.Timed.dll", etc.)? Not every app will
| use every one, of course. But with a strategy of dividing the DLLs into
| very discrete uses, I could quickly get 30 or 40 dependencies for each
| application.
|
| I realize this is a philosophical question! Just curious if there's a
| "best practice."
|

 

[Ray Cassick \(Home\)]

If I am going to take a bunch of 'things' and put them into different
classes the first thing I do is create a dependency chart so I can see what
depends upon what. The last thing you want to do is end up creating a
circular reference type deal.

Doing this also help to determine what 'things' are logically used together
allot and this helps you keep the number of libraries that need to be
distributed down. Keep things that are often used together in the same
library.