Sometime getting good guidance on certain basic topics seems harder then it should be. Conventions and best practices for assembly names is an area that seems so simple you feel foolish asking the question. However, what seems like a simple issue really deserves to be well thought out and grounded on sound principles and good information.
In addition to the naming of assemblies, the folder structure in which we house or development solutions and projects requires some thought and structure.
Below are some recommendations on the two topics.
Define a Common Root Folder
Define a common root folder—for example, C:\development on your file system. This acts as a container for all of your development systems and matches your toot namespace.
Beneath the common root folder, create sub folders for each sub namespace such as c:\development\Data. Within each namespace folder create folders to house your solutions such as c:\development\Data\myCompanyData_Solution.
Use Common Names for Projects and Assemblies
Your output assembly name should always match the project name from which it is generated. For example, you should be able to assume that an assembly called MyCompany.Utilities.Data.dll is generated by a project called MyCompany.Utilities.Data.
If you change the name of an output assembly, consider changing the project name to match, and vice-versa.
Use a Common Root Namespace Name
The root namespace into which you place your types (structures, classes, interfaces, and so on) should match the project and assembly name.
For example, use MyCompany.Utilities.Data as the root namespace within the MyCompany.Utilities.Data.dll assembly.
While .NET does not require this alignment, it makes sense to synchronize names because it then becomes easy to tell which types live in which assemblies.
Use a dot separated naming convention
Microsoft.Windows.Forms.dll
<Company>.<Major sub system>.dll
<Company>.<Major sub system>.<minor sub system>dll
Posts
No comments:
Post a Comment