SharePoint Solutions – Building and Deployment Best Practices

SharePoint solution best practices: Based on my experience, here are the best practices w.r.t solutions management in SharePoint.

1. Every customization must be a Feature-based solution. Doesn’t matter if it’s a Webpart/Event Handler/InfoPath/Content Types or file system change. You can group the features together as solutions. The solution should have event handlers for “Feature activating” and “Feature Deactivated” events wherever applicable. Place the appropriate code in respective blocks. It’s a best practice to have an uninstallation module in place.

2. Be Descriptive: Ensure that all the features has a appropriate name, description, updated version number, optionally icons.

3. Follow the Four-part naming or at least Three-part naming in Name Spaces, Solution names, and in the Target location of the solutions. Don’t just place them inside the features folder, But create a four/three-part naming folder for each feature and place the supported files inside.   for e.g., rather “statusreport”, It would be more meaningful if it is: Company.Sales.StatusReport.WebPart, Isn’t it? This will avoid conflicts and provides better manageability.

4. Follow coding standards. Each and every Solution must be thoroughly evaluated line-by-line and tested in DEV, TEST, and then moved to PROD environments. We will do the code review before moving to DEV even. Follow the coding standards(even in variable naming! Preferably PascalCase/camelCase)

5. Avoid debugging solution in PROD environment. You can write your code in such a way, Errors are getting logged in to the Event Log / Custom Log file. Fix them in DEV at least. So that it would be easier for de-bugging.

6. We must not deploy debug mode assemblies in PROD – Remove all your Break-Points, and debug codes before packing for PROD. Make sure your code and packages are compiled in release mode.

7. Avoid any manual changes. All changes must be automated. Even a web.config changes should be scripted. Adding Configurable Properties to a SharePoint Web Part’s Tool Pane is preferable.

8. Pay more attention to the Documentation!!!. Pretend like you are giving instructions to the person who doesn’t know anything about the particular solution. We need guides which should contain

  • Solution abstract, flow, name and version number.
  • Activities, configurations, packages, etc. that should be installed or performed before/after the package installation.
  • Deployment steps: Detailed steps to deploy or retract the package.
  • Unit Test: How to validate that the package is deployed successfully.
  • provide the exact steps. 

9. Never deploy SharePoint DLLs along with your WSP!!! –  what’s the consequences – You will damage SharePoint. How? Your different versions DLL’s from Development box will cause In-compatible operations with PROD SharePoint environment.

10. Never Modify SharePoint’s files in File system. If you must modify have a backup and make the change as solution.  E.g. Changing the Core.CSS file for branding.. If you Change the file, It may be overwritten when applying service pack. Never Modify SharePoint Databases!

11. Use WSP Builder Project Template, Use Visual Studio 2008  – No Manual DDF files generation! Use Relative Links Whenever Possible.

12.  Maintain versions along with change history in solutions.  The assembly version number should be as the solution version number and should be incremented (format V#.#.#).  So that we can do upgrade solution, which is faster than going through the complete cycle, it does only upgrade existing features.

13. Use version control system, Like SVN, CVS, TFS and keep all the related artifacts there.

14. Double check your Object disposals. use https://code.msdn.microsoft.com/SPDisposeCheck

15. Don’t hard code the parameters in the code, But make them configurable properties.

16. Handle the exceptions properly. Use Try{} Catch{} Finally{} Blocks.

17. Use SPQuery instead of SPList.items when retrieving from Large lists/libraries.

18. Last but not least: Provide excessive comments, Summary in code wherever applicable  E.g. Use summary on functions like this:
       ///  <summary>
       ///  Function’s Summary
       ///  </summary>
       ///  <param Name=”param1″>
       ///  Why we need param1?
       ///  </param>
       ///  <returns>
      /// What we get from the function
       ///</returns>

Check out my Presentation: Best practices for share point solution deployment

Related Read: 10 best practices for building SharePoint solutions from MSDN

Salaudeen Rajack

Salaudeen Rajack - Information Technology Expert with Two-decades of hands-on experience, specializing in SharePoint, PowerShell, Microsoft 365, and related products. He has held various positions including SharePoint Architect, Administrator, Developer and consultant, has helped many organizations to implement and optimize SharePoint solutions. Known for his deep technical expertise, He's passionate about sharing the knowledge and insights to help others, through the real-world articles!

Leave a Reply

Your email address will not be published. Required fields are marked *