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

i always do .Core.dll.

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.

Answer 4

I've used .Core, .Framework, and .Common.

Answer 5

The one I use most common and seem to love because I don't see other people use it is Root

I'll generally do

CompanyName.Root

or

SomethingMeaningfulToMe.Root

Answer 6

We use this model:

• Company.Core.dll
• Company.WinControls.dll
• Company.WebControls.dll
• Company.Product.Core.dll
• Company.Product.WinControls.dll
• Company.Product.WebControls.dll

etc.