Naming a "core" Assembly

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.

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.

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

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.