assembly naming conventions

Question

Assuming you have a namespace that is useful to more than one project in your company, in the format of "MyCompany.Core", would you have an assembly named exactly the same way or just "Core". Why or why not?

Answer 1

Use the standard .NET naming conventions, assembly names are covered here . I'll save you the (short) read:

Do choose names for your assembly DLLs that suggest large chunks of functionality such as System.Data. Assembly and DLL names do not have to correspond to namespace names but it is reasonable to follow the namespace name when naming assemblies.

Consider naming DLLs according to the following pattern:
<Company>.<Component>.dll
Where <Component> contains one or more dot-separated clauses.

For example, Contoso.WebControls.dll.

Answer 2

I believe it's best (opinion here!) to name the assembly after the root namespace it contains, in your case MyCompany.Core.dll . You never know if that file will make its way outside the company, and keeping track of it is just easier in general.

Imagine if Microsoft named System.Core just Core.dll (System.Core) , then you had Core.dll (MyCompany.Core) ....you imagine how that gets hairy fast.

Answer 3

我更喜欢MyCompany.ApplicationName.Core.DLL，如果MyCompany有两个或更多应用程序，这可以消除冲突的可能性。

Answer 4

I would name the assembly the same as the root namespace. This makes it easy to figure out what code is in which assembly, and prevents collisions with other projects (from other companies) that might also be using the ambiguious name "Core.dll".

Answer 5

if developing in a enterprise environment, this convention may be useful:

Namespaces follow the [DomainEntityName].[AssemblyName].[Purpose].[RelatedPurpose] format where the DomainEntityName is the root business functionality name and the AssemblyName is the functionally that is supporting the Business requirement.