Naming a "core" Assembly

Question

I know that this is somewhat subjective, but I wonder if there is a generally accepted standard for naming assemblies which contain some "core" functions.

Let's say you got a larger Projects, with Assemblies like

• Company.Product.WebControls.dll
• Company.Product.Net.dll
• Company.Product.UserPages.dll

and you have a Bunch of "Core" classes, like the Global Error Handler, the global Logging functionality etc.

How would such an assembly generally named? Here are some things I had in mind:

• Company.Product.dll
• Company.Product.Core.dll
• Company.Product.Global.dll
• Company.Product.Administration.dll

Now, while "just pick one and go on" will not cause Armageddon, I'd still like to know if there is an "accepted" way to name those assemblies.

Answer 1

All these "root", "core", "common" and so on, are probably not the best naming-conventions.

Common stuff should lie in the root namespace, like in .NET, string, int and other things that are "core" or "common" lies in the root System-namespace.

Don't use namespaces to more easily collapse your folders in Visual Studio, but structure it after what it contains and what it's used for.

System.Security contains common security-things that, for example System.Xml doesn't need to know about, unless you want that functionality explicitly.

System.Security.Cryptographyis a sub-namespace. Cryptography is security, but security is not explicitly cryptography.

In this way System.Security.Cryptography has full insight into it's parent namespace and can implictly use all classes inside of its parent.

I would say System.Core.dll was a slip-up on Microsoft's side. They must have ran out of ideas or DLL-names.

Update: MSDN has a somewhat updated article that tries to explain Microsoft's thinking on the subject.

Answer 2

With .Net this is relatively easy to change, so I'd go with convenience.

Fewer, larger, assemblies compile quicker than many small ones, so I'd start with your 'core' stuff as a namespace inside Company.Product.dll, and split it out later if you need to.

Answer 3

I typically like to have names which describe what is inside each assembly.

You see, if you name something as .Core, then on a large team, it can grow very quickly as people would consider putting very common thing in that assembly.

So, I think that there shouldn't really be one core assembly.