| 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
"Graham Charles" <gr****@aiid.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...
| 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."
|