Saturday, July 4, 2015

Do and Don't do n SharePoint Developement ,Best practices In SharePoint 2013,2010

When creating new columns, name them without any special characters or spaces.  After the column is created, rename it with the special characters or spaces.  This way the internal name is "clean".
When you are working with DataViews, some third party controls, and custom Webparts - you must use the internal name.  The potential for confusion is enormous.
When you are adding sites and pages make sure their names don't have spaces.

URLs
When adding pages or sites to your navigation, always browse to the intended destination; this will ensure your tabs will work properly.  In fact if you compare the resulting URL after you fix a broken tab this way, you will see that the URL must be relative, not absolute.

Use the same practice of giving the relative URL instead of the absolute URL in the Content Editor Webpart or Master Pages or in any other circumstance where you are required to provide the URL.

Whenever there is a requirement to change the URL in the Master Page wherein the Mater Page has been deployed as a feature, always change the link in the Master Page which is residing inside the Feature Folder and do not use SharePoint Designer to open a Site and Change the Link.

Backup/Restore or Export/Import

Never use Back Up and Restore procedure if you are trying to restore a Site Collection which is using Collaboration Portal, instead use Export and Import.

Same applies to saving of a collaboration site as template. MS does not support this.

STSADM
Get familiar with the various stsadm.exe commands. It helps a lot and saves time.
STSADM commands has been deprecated and will not be supported in future releases of Microsoft Sharepoint Foundation 2010.

SP Designer
Avoid using SharePoint Designer to edit any page design as much as possible. This causes a lot of performance issues.

Hive older backup
Please take the backup of the 12/14 hive if you are trying to do any changes inside the 12/14 hive.

Rollback Plan

Always have the rollback plan ready whenever you are deploying anything on the web server as SharePoint is very unstable so you would never know what is causing the problem very soon.

General
Learn to use the SharePoint object model efficiently.

Make sure that you always Dispose() the SPSite and SPWeb object in the finally block of your code.

Whenever you are required to loop through something, use for loop instead of foreach loop.

Try to avoid looping as much as possible. See if the same can be achieved through CAML query or SiteData Query or by using Search Object Model which actually fires the query on the crawled results.

Even if you are looping, try to reduce the number of loops as much you can.

Modularize your code and divide them into different parts depending on their functionality. Do not write bulky code.

Always put all your functions in try-catch block.

Never do any sort of Hard-Coding in your code.

Whenever there is more than one content DB for a web application for any reasons. Make sure that all the newly created sites goes to a particular content DB only and the data should not be going randomly to all the content DB’s. You can do this by setting the limitation for the number of sites in one of the content DB where you do not want the new data to go.

Make use of time bound caching wherever you are not required to show the real time data. Also you can use caching when you’re are pulling out data from a database and showing it in your Webpart. You have to set the Sql Dependency for the same.

Using Objects in Event Receivers
Do not instantiate an SPWeb, SPSite, SPList, or SPListItem object within an event receiver. Event receivers that instantiate these objects instead of using the instances passed via the event properties can cause the following issues:

Significant additional round-trips to the database (one write operation can result in up to five additional round-trips in each event receiver).
Calls to the Update method on these instances can cause subsequent Update calls in other registered event receivers to fail.
Usage of OOB files

Do not change OOB files. OOB files can be .aspx, .ascx ,.xsl, .xml, .js,.css  etc under 14 hive directory. Changing OOB can cause huge issues which cannot be traceable and changes will be visible to all applications that are running in the farm. If you want to use OOB files for customization purpose, create new folders, make a copy of the file and have it in the new folder and customize it.
For example,
If you wanna use/customize approve.aspx, create a new folder under  1033/layouts/<application name> , copy approve.aspx from 1033/layouts/ and paste it under 1033/layouts/<application name> and then customize it.

No comments:

Post a Comment