Naming

Intention

Beside the naming conventions of the .NET Framework Design Guidelines (which applies for code in assemblies) SharePoint code needs additionally naming conventions to cover code in XML files (like Features, ContentTypes), naming of deployed files and naming of IDs in XML code. The following sections describe the additional SharePoint naming conventions and provide an index of naming rules of SPCAF.

• Naming of Solution Files
• Naming of Features
• Naming of Assemblies
• Naming of Files and Folders
• Naming of IDs
• Index of Naming Rules

Naming of Solution Files

Typically a SharePoint application consists of multiple WSP solutions. Although it is a best practices to reduce the number of WSP packages it is often necessary, to split the code of an application into separate packages. Furthermore in most cases Solution packages from different vendors or different applications are deployed to the same SharePoint farm. Thus, it is necessary to use a strict naming convention for Solution packages.

To achieve unique naming of Solution packages in the Solution Gallery a namespace should be used for the package file. This name should follow the existing Namespace Naming Guidelines of .NET. Adjusting these guidelines to SharePoint the name of the solution package should start with the company name, followed by name of the application or project:

Sometimes it is necessary to deploy the same application in different versions into SharePoint. In this case it should be recongnizable for the administrator to see the dependencies between both applications by a version number. To avoid long version numbers in the solution name only the major version should be added to the name. The version number should be the last part of the solution filename:

Additional reasons for multiple SharePoint solutions packages are:

• Separation depending on deployment scope of farm solutions (deployment globally or per WebApplication)
• Separation of Assemblies from SharePoint files, e.g. to reduce IISReset during deployment
• Separation of global Resources from the rest of the code to support LanguagePacks for an application
• Separation of independent components, like 'Webparts', 'Services', 'WebServices'
• Separation depending on deployment model (farm solutions vs. sandboxed solutions)

To reflect the different types of Solutions the following naming conventions are used to make the differences visible. This may help SharePoint administrators to see which type of solution is deployed into the farm or to a sitecollection in the 'Solution Gallery'.

Naming of Features

Features are deployed to folder \TEMPLATE\FEATURES and therefore the folder name must be unique. The name of the feature folder should start with the name of solution which deploys the feature, an underscore and the name of the feature (which must be unique within the solution). .

Naming of Assemblies

In general assemblies should follow the .NET Framework Design Guidelines.

In SharePoint the name of assemblies should contain the name of the Solution package which deploys the assembly. For instance, if assemblies are deployed in Solution file MyCompany.CorporateIntranet.CoreComponents.wsp, the assemblies in this package should start with MyCompany.CorporateIntranet.CoreComponents, for instance MyCompany.CorporateIntranet.CoreComponents.Services.dll. Especially if assemblies are deployed to GAC this approach helps to see the relation between the assembly and the solution package which deployed the assembly.

Naming of Files and Folders in Package

The most critical part is the naming of deployed files and folders. A wrongly named file can make SharePoint inaccessible, e.g. if a SharePoint system file is replaced accidentally. Furthermore if SharePoint code from different vendors or different applications is deployed it is important to use unique names for folder and files.

All files and folders are deployed by a WSP solution package. To ensure uniqueness of the names and to make the relation between the package and the files visible the name of the solution package should be part of the file or folder.
To avoid characters '.' in the name of folders and files this character should be replaced by underscore.

If possible files should not be deployed directly into a SharePoint system folder. A subfolder should be created instead. The name of the folder should be unique and therefore should contain the namespace of the solution package.

Several files cannot be deployed into a custom subfolder and must be deployed directly into a SharePoint system folder. Samples are:

• Control templates (must be deployed file to \TEMPLATES\CONTROLTEMPLATES)
• FieldTypes (must be deployed as .xml file to \TEMPLATES/XML)
• Custom SiteDefinitions (must be deployed as .xml file to \TEMPLATE\1033\XML)
• Global Resources (must be deployed as .resx file to \Resources)

Naming of IDs

Several components contain attributes (like IDs) which must be unique across the farm. Often a GUID can be used for these attributes (e.g. for FeatureID). Sometimes it is better to use a readable name for IDs instead of using a GUID. For these IDs the namespace of the solution package should be part of the attribute.

Index