Assembly/DLL Naming Guidelines

I have not seen this be much of debate externally, but it
has been pretty hotly debated internally.  We just closed down on this
guideline... As always, your comments are welcome:

2.3.4 Assembly/DLL Naming Guidelines

An assembly is the
unit of deployment and security for managed code projects. Typically
an assembly contains managed code and maps 1-1 with a DLL, although assemblies can span one or more files and may
contain managed and unmanaged code as well as non-code files such as
resources.

Assemblies are self-describing
units of compiled managed code. When assemblies are in more than one file, there
is one file that contains the entry point and describes the other files in the
assembly. A Module is compiled code that can be added to an
assembly but has no assembly or version information of its own.

You should choose names for your assemblies
that suggest large chunks of functionality such as System.Data. Assembly
and DLL names don’t correspond to namespace names but it is reasonable to follow
your namespace [mcm1] conventions[mcm1] when naming assemblies.

?     
Consider naming managed DLLs
according to the following pattern:

<Company>.<Component>.dll

Where <Component> contains one or more
dot-separated clauses. For example,

Microsoft.VisualBasic.dll
Microsoft.VisualBasic.Vsa.dll
Microsoft.Directx.dll
System.Web.dll
System.Web.Services.dll
Fabrikam.Security.dll
Litware.Controls.dll

FxCop rule coming.

Please keep in mind that namespaces are
distinct from DLL names. Namespaces represent logical groupings for
developers whereas DLLs represent packaging and deployment boundaries.
DLLs can contain multiple namespaces for product factoring and other reasons,
and namespaces can span multiple DLLs. Since namespace factoring is
different than assembly factoring, you should design them
independently.

 [mcm1]Make this a hyperlink to 2.3
Namespaces