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