SharePoint Development Standards

This is only meant as application specific standards. You should always review these standards along with regular development standards which identify things like naming conventions and approaches.

General Principals:

· All new functionality and customizations must be documented.

Do not edit out of the box files.

For a few well defined files such as the Web.config or docicon.xml files, the built-in files included with SharePoint Products and Technologies should never be modified except through official supported software updates, service packs, or product upgrades.

Do not modify the Database Schema.

Any change made to the structure or object types associated with a database or to the tables included in it. This includes changes to the SQL processing of data such as triggers and adding new User Defined Functions.

o A schema change could be performed by a SQL script, by manual change, or by code that has appropriate permissions to access the SharePoint databases. Any custom code or installation script should always be scrutinized for the possibility that it modifies the SharePoint database.

· Do not directly access the databases.

o Any addition, modification, or deletion of the data within any SharePoint database using database access commands. This would include bulk loading of data into a database, exporting data, or directly querying or modifying data.

o Directly querying or modifying the database could place extra load on a server, or could expose information to users in a way that violates security policies or personal information management policies. If server- side code must query data, then the process for acquiring that data should be through the built-in SharePoint object model, and not by using any type of query to the database. Client-side code that needs to modify or query data in SharePoint Products and Technologies can do this by using calls to the built-in SharePoint Web services that in turn call the object model.

§ Exception: In SharePoint 2010 the Logging database can be queried directly as this database was designed for that purpose.

· In SharePoint 2007 site and list templates must be created through code and features (site and list definitions). STP files are not allowed as they are not updatable.

Use best practices when accessing data using the SharePoint object model. See Working with Large Lists, Common Coding Issues When Using the SharePoint Object Model, and Using Disposable Windows SharePoint Services Objects

Development Decisions:

There are plenty of challenging decisions that go into defining what the right solution for a business or technical challenge will be. What follows is a chart meant to help developers when selecting their development approach.

	Sandbox	Apps	Farm
When to use	Deprecated. Therefore, it’s unadvisable to build new sandboxed solutions.	Best practice. Create apps whenever you can.	Create farm solutions when you can’t do it in an app. See http://www.learningsharepoint.com/2012/07/20/sharepoint-2013-apps-vs-farm-solutions/ for more info.
Server-side code	Runs under a strict CAS policy and is limited in what it can do.	No SharePoint server-code. When apps are hosted in an isolated SharePoint site, no server-code whatsoever is allowed.	Can run full trust code or run under fine grained custom CAS policies.
Resource throttling	Run under an advanced resource management system that allows resource point allocation and automatic shutdown for troublesome solutions.	Apps run isolated from a SharePoint farm, but can have an indirect impact by leveraging the client object model.	Can impact SharePoint server-farm stability directly.
Runs cross-domain	No, and there’s no need to since code runs within the SharePoint farm.	Yes, which provides a very interesting way to distribute server loads.	No, and there’s no need to since code runs within the SharePoint farm.
Efficiency/Performance	Runs on the server farm, but in a dedicated isolated process. The sandbox architecture provides overhead.	Apps hosted on separate app servers (even cross-domain) or in the cloud may cause considerable overhead.	Very efficient.
Safety	Very safe.	Apps rely on OAuth 2.0. The OAuth 2.0 standard is surrounded by some controversy (for example, check out what OAuth lead author Eran Hammer has to say about it here: http://hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell/ . In fact, some SharePoint experts have gone on the record stating that security for Apps will become a big problem. We’ll just have to wait and see how this turns out.	Can be very safe, but this requires additional testing, validation and potential monitoring.
Should IT pros worry over it?	Due the the limited CAS permissions and resource throttling system, IT pros don’t have to worry.	Apps are able to do a lot via the client OM. There are some uncertainties concerning the safety of an App running on a page with other Apps. For now, this seems to be the most worry-able option, but we’ll have to see how this plays out.	Definitely. This type of solutions run on the SharePoint farm itself and therefore can have a profound impact.
Manageability	Easy to manage within the SharePoint farm.	Can be managed on a dedicated environment without SharePoint. Dedicated app admins can take care of this.	Easy to manage within the SharePoint farm.
Cloud support	Yes	Yes, also support for App MarketPlace.	No, on-premises (or dedicated) only.

App Development (SharePoint 2013):

· When developing an app select the most appropriate client API:

o Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server separated by a firewall benefit most from using the JavaScript client object model.

o Server-side code in Apps that offer Create/Read/Update/Delete (CRUD) actions against SharePoint or BCS external data, and are hosted on an application server but not separated by a firewall mainly benefit from using the .managed client object model, but the Silverlight client object model, JavaScript client object model or REST are also options.

o Apps hosted on non-Microsoft technology (such as members of the LAMP stack) will need to use REST.

o Windows phone apps need to use the mobile client object model.

o If an App contains a Silverlight application, it should use the Silverlight client object model.

o Office Apps that also work with SharePoint need to use the JavaScript client object model.

Quality Assurance:

Custom code must be checked for memory leaks using SPDisposeCheck.

False positives should be identified and commented.

Code should be carefully reviewed and checked. As a starting point use this code review checklist (and provide additional review as needed).
Provide an Installation Guide which contains the following items (Note this relates to SharePoint Deployment Standards):

Solution name and version number.
Targeted environments for installation.
Software and hardware Prerequisites: explicitly describes what is all needed updates, activities, configurations, packages, etc. that should be installed or performed before the package installation.
Deployment steps: Detailed steps to deploy or retract the package.
Deployment validation: How to validate that the package is deployed successfully.
Describe all impacted scopes in the deployment environment and the type of impact.

Branding:

A consistent user interface should be leveraged throughout the site. If a custom application is created it should leverage the same master page as the site.
Editing out of the box master pages is not allowed. Instead, duplicate an existing master page; make edits, then ensure you add it to a solution package for feature deployment.
When possible you should avoid removing SharePoint controls from any design as this may impact system behavior, or impair SharePoint functionality.
All Master Pages should have a title, a description, and a preview image.
All Page Layouts should have a title, a description, and a preview image.

Deployment:

All custom SharePoint work should be deployed through SharePoint Solution (.wsp) files.
Do not deploy directly into the SharePointRoot (12-Hive, 14-Hive) Folders. Instead deploy into a folder identified by Project Name.

Features:

Features must have a unique GUID within the farm.
Features with event receivers should clean up all changes created in the activation as part of the deactivation routine.

The exception to this is if the feature creates a list or library that contains user supplied data. Do not delete the list/library in this instance.

Features deployed at the Farm or Web Application level should never be hidden.
Site Collection and Site Features may be hidden if necessary.
Ensure that all features you develop have an appropriate name, description, updated version number and icon.

SharePoint Designer:

SharePoint Designer 2007 updates are generally not allowed.

The only exception to this rule is for creating DataForm Web Parts.
The following is a recommended way of managing this aspect:
Create a temporary web part page (for managing the manipulation of a data view web part). Once the web part is ready for release and all modifications have been made export the .webpart and then delete the page. You can now import it onto a page elsewhere or place it in the gallery. This way none of your production pages are un-ghosted. The other advantage is that you can place the DVWP on a publishing page (as long as there are web part zones to accept them).
DataForm Web Parts should be exported through the SharePoint GUI and solution packaged for deployment as a feature.
This does not mean that SharePoint Designer should not be used for creating and testing branding artifacts such as master pages and page layouts.

It is important for these artifacts to be deployed through solution files (WSPs) and typical build and deployment processes and not by manual methods.

SharePoint Designer 2010 updates are generally only allowed by a trained individual.

The following is a recommended way of managing the creation of DataForm Web Parts:
Create a temporary web part page (for managing the manipulation of a data view web part). Once the web part is ready for release and all modifications have been made export the .webpart and then delete the page. You can now import it onto a page elsewhere or place it in the gallery. This way none of your production pages are un-ghosted. The other advantage is that you can place the DVWP on a publishing page (as long as there are web part zones to accept them).
DataForm Web Parts should be exported through the SharePoint GUI and solution packaged for deployment as a feature.

SharePoint Designer workflows should not be used for Business Critical Processes.

They are not portable and cannot be packaged for solution deployment.

Exception Note: Based on the design and approach being used it may be viable in SharePoint 2010 for you to design a workflow that has more portability. This should be determined on a case by case basis as to whether it is worth the investment and is supportable in your organization.

Site Definitions:

In SharePoint 2007 site and list templates must be created through code and features (site and list definitions).

STP files are not allowed as they are not updatable.

Site definitions should use a minimal site definition with feature stapling.

Solutions:

Solutions must have a unique GUID within the farm.
Ensure that the new solution version number is incremented (format V#.#.#).
The solution package should not contain any of the files deployed with SharePoint.
Referenced assemblies should not be set to “Local Copy = true”
All pre-requisites must be communicated and pre-installed as separate solution(s) for easier administration.

Source Control:

All source code must be under a proper source control (like TFS or SVN).
All internal builds must have proper labels on source control.
All releases have proper labels on source control.

InfoPath:

If an InfoPath Form has a code behind file or requires full trust then it must be packaged as a solution and deployed through Central Administration.
If an InfoPath form does not have code behind and does not need full trust the form can be manually published to a document library, but the process and location of the document library must be documented inside the form.

Just add the documentation text into a section control at the top of the form and set conditional formatting on that section to always hide the section, that way users will never see it.

WebParts

All WebParts should have a title, a description, and an icon.

Application Configuration

· There are only a few methods in which application configuration data can be stored. When selecting the option that is right for the situation any decision maker must review this article Managing Custom Configuration Options for a SharePoint Application before making the decision.

o Web.config

§ APIs such as the ConfigurationSection class and SPWebConfigModification class should always be used when making modifications to the Web.config file.

§ HTTPModules, FBA membership and Role provider configuration must be made to the Web.config.

o Property Bags

§ It is recommended that you create your own _layouts page for your own settings.

§ It is also recommended that you use this codeplex tool to support this method http://pbs2010.codeplex.com/

o Lists

§ This is not a recommended option for Farm or Web Application level configuration data.

§ It is also recommended that you use this codeplex tool to support this method http://spconfigstore.codeplex.com/

o Hierarchical Object Store (HOS) or SPPersistedObject

§ Ensure that any trees or relationships you create are clearly documented.

§ It is also recommended that you use the Manage Hierarchical Object Store feature at http://features.codeplex.com/. This feature only stores values in the Web Application. You can build a hierarchy of persisted objects but these objects don’t necessarily map to SPSites and SPWebs.

Rajshekar Indoori -Sharepoint , O365 ,AZURE , Devops, Snowflake and RPA expert

Monday, July 4, 2016