ConfigLabs

August 19, 2008

SharePoint Development Best Practices – Checklist

Filed under: Microsoft, Programming, Project Management, SharePoint 2007, Software Engineering, WSS 3.0, Webparts — Jag @ 10:59 am

Today, I came across a checklist for SharePoint Custom Solution Code Acceptance. I reckon this checklist (modified if necessary) should be part of your test plans if your SharePoint Project needs custom solution bits. Code acceptance checklist outlines best practices for security, session management, validation, sensitive data, exception handling, Web parts, documentation, general software development. I think it is very important for any SharePoint developer to keep these best practices in mind. Of all the best practices I feel every SharePoint developer (novice to experienced) should at least follow ‘Web part development’ and ‘general software development’ best practices as a mantra!!

Best Practices for SharePoint Web part Development:

  1. Custom Web parts (including resource files) are contained within a SharePoint Feature and are packaged as a SharePoint solution in order to be deployed.
  2. The configuration of Web parts that are being deployed gives the administrator the flexibility of deploying to the Web application level or lower.
  3. You use the SharePoint Web part infrastructure’s standardized set of connection interfaces for Web parts to exchange information with each other at run time.
  4. Source code for third party Web parts solutions, whenever possible, is provided with adequate documentation to ensure good technical support.
  5. All custom Web parts utilize the SharePoint architecture to ensure consistent behaviour across the application for functionality such as single sign-on, feature deployment, and so on.

Best Practices for General SharePoint Software Development:

  1. Assemblies have a strong name. (Dynamically generated ASP.NET Web page assemblies cannot currently have a strong name.)
  2. You use delay signing as a way to protect and restrict the private key that is used in the strong name and signing process.
  3. Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specify minimum permission requirements.
  4. Highly privileged assemblies are separated from lower privileged assemblies.
  5. If an assembly is to be used in a partial-trust environment (for example, it is called from a partial-trust Web application), then privileged code is in a separate assembly.
  6. You rely on a native configuration file to support the application instead of changing the configuration to the Web.config.
  7. You use .NET Framework 2.0, 3.0, or 3.5.
  8. You use a single .NET Framework version. You do not mix multiple versions.
  9. Your code is 64 bit compatible.
  10. Your application does not try to directly access any SharePoint databases. Data stores in SharePoint databases are only updated by using the SharePoint object model.
  11. You avoid hard coding strings and labels. You use resources or language files instead.
  12. When referencing the SPWeb or SPSite objects, you employ a using statement or, alternatively, you use an explicit call of the .Dispose method to ensure proper use and disposing of the memory objects.
  13. You use caching as appropriate to reduce unnecessary round trips. For Web parts, you expose the cache expiration (duration) as a Web part property.
  14. When packaging your solution, you include a Code Access Security policy for the solution and, if necessary, include your assembly in the Safe Controls list though the solution.
  15. When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS) logs.
  16. If you need to update multiple list items by using remote code, you use the Web service to update list items. You only use SPListItem.Update() if you have to update more than one item at a time by using local OM-based code.
  17. When using the Count property of a SPListItemCollection, you only call it once and then store it in a variable that you can refer to when looping. You do not call it inside a loop.
  18. The solution uses the AppSettings object to implement XML mapping. (This can be provided by using the settings persistence framework in .NET 2.0, 3.0, or 3.5.) The solution avoids creating custom XML files and a strongly typed object for XML mapping.
  19. Installation and deployment logging are provided in the event logs to enable appropriate operational troubleshooting during installation and uninstallation.

Please note that, the best practices are not limited to ones mentioned above. Best Practices are something which evolve with experience. If you know of any other best practices which you think are worth sharing don’t hesitate to share them in comments.

For other best practices please refer to Sample code acceptance checklist for IT organizations.

For a printable version of the sample code checklist that you can edit, download the list as a Word 2007 document (.doc).

Sample code acceptance checklist for IT organizations (http://go.microsoft.com/fwlink/?LinkId=125134)

Additional Resources for Best Practice SharePoint Development

July 20, 2007

SharePoint Developer’s rant about PM

Filed under: Project Management, SharePoint 2007 — Jag @ 6:14 am

This post is definitely the best one so far this month! I simply can’t resist myself from posting the link to this article. May be just because it fits to my case so nicely that I can relate to each one of the points.

Being a SharePoint developer, I am finding myself midst of projects either failed in the previous attempt or the ones that are dragged for so long. I am just amazed about, why this is happening in the first place? The answer to the question depends on whom you ask! 

Anyway, enough of this…. here is the link 10 Steps To Effective SharePoint Project Management

Well done Adam, very good one indeed.

Blog at WordPress.com.