First of all, you don't reference DLL's, you only reference assemblies. Do you think there is no difference? There is… An assembly usually has one
module, which can be .DLL, .EXE (you can freely reference an assembly by an .EXE module — did you know that? in some cases, rather exotic ones, it even makes big practical sense; and this is not a trick) or anything else. But this is not necessarily so. .NET allows multiple modules per assembly, and, physically, only one of those modules has an assembly manifest. At the same time, the same module can be reused in more than one assembly. This is supported by compiler's command line, but not directly by Visual Studio. Let's set it aside. Here, it's only important that you reference assemblies, not modules. And the use of the module by an assembly is similar to referencing, but is something different.
Now, you should understand that the boundaries between assemblies are not very strong. Your types and dependencies between them are more important. So, start with the design of your code with main classes, and, when you come to something, you can change distribution of types between assemblies. If you make some mistake, you can relatively easily move one class from one assembly to another. In worst case, you will have to change some
internal
access specifiers to
public
, and visa versa. All other access specifiers remains the same. When you look at my past answer referenced below, pay
special attention for my words
in bold.
Now, I recommend to divide your code primarily not by "topics" (networking, UI, and so on), but first,
by layers. These principles are explained here:
How Do I Divide My Code Appropriately?.
See also my notes on more advanced kinds of architectures, with plug-ins:
Projects and DLL's: How to keep them managable?.
Finally, one practical advice: merge your output directories to one, separately per configuration. It can be done automatically:
Manage output Files and Folders (Debug/release) in VS C#.,
VB.net. Bring all files over with referenced .NET dlls files when compiling..
—SA