Some Things To Get Excited About With SharePoint 2010

Random things that I’m looking forward to with SharePoint 2010:

  • Managed Metadata Service
  • Enterprise Content Types
  • Tagging and Rating (Taxonomy & Folksonomy)
  • Content Organizer (routing content based on pre-set policies)
  • Records Management (in place or upload to record center)
  • Delete, Hold in-place, Archive with Link options
  • Social features, social search, social bookmarking, search for user content
  • My Sites: Customizable My Site templates, org chart, user’s activity feed
  • User Profile Service; Sync data from multiple sources into SharePoint profile
  • Unique document IDs (HUGE!)
  • SharePoint Workspace for offline collaboration
  • Office Web applications

Yes, a bit heavy on the social networking and content metatagging side, but that’s the stuff that gives users control while still being able to intelligently manage all that data!

Developing SharePoint 2007 – Application Guidance

This guidance helps architects and developers design, build, and test intranet and enterprise-scale SharePoint applications. Two reference implementations demonstrate solutions to common issues, and a library provides reusable components that can help you with your own development projects.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=13284

Importance of Standards in SharePoint Development

So I’m going to spend a few moments on my soapbox here…

SharePoint is an amazing application platform and through the use of many different 3rd party tools and custom code it can do just about anything.  As developers who know SharePoint we may be tempted to custom code something that is similar to SharePoint functionality, but just needs a few little tweaks to be perfect for the business.

This is such a dangerous path.  Most SharePoint developers are .NET developers, but not all .NET developers are SharePoint developers.  Due to the restrictions that SharePoint places on the code, often times I find that .NET developers code around these “limitations” which can cause security and coding issues down the road.

That being said, here are some quick bullet points to get started:

Assembly Development:

File Headers:

  • In the top section of each file (code, xml, aspx, etc) supply the following information:
    • Company name and copy rights
    • Author name
    • File
    • Purpose
    • Create Date

Custom Configuration:
Config File:

  • When possible try to not store custom settings in the web.config file. Use a separate file on CONFIG folder.
  • File name should follow this format:
    • [Customer]_[Supplier Name]_[Solution name]_Configuration.config example:Adventureworks_JSolutions_Branding_Configuration.config
  • Entries to web.config keys must be communicated beforehand to the customer.
  • Entries to web.config (user names or passwords) must be encrypted.
  • Entries to the web.config should be inside a block of comment which contains the solution name and description.

Property Bag:

  • Should be used for storing only primitive types.
  • If the values are user-defined, provide a web interface to edit those properties from custom actions on central administration on each property scope.

Features:

  • Ensure that each feature GUID is unique in the farm.
  • Ensure that each feature folder name and title should follow this format:
    • [Customer].[Supplier Name].[Solution name].[Feature Name]
    • example: Adventureworks.JSolutions.Branding.HideLinks
  • Ensure that all the features has a appropriate name, description, updated version number and icon.
  • Features with event receivers should clean up all changes created in activation as part of the deactivation routines. If the feature creates a list that contains user data, the feature should not delete this list.
  • Farm and Web Application features should never be hidden.
  • Site Collection and Site features should be hidden.

Solution (WSP):

  • Ensure that new solutions have a unique GUID in the Farm
  • Ensure that the new solution version number is incremented (format V#.#.#)
  • Solution naming convention must be descriptive:
    • [Client Name].[Supplier Name].[Solution or module name]_[Version number].wsp
    • example: Adventureworks.JSolutions.Branding_v1.0.0.wsp
  • In case of an update solution action is required for installation,solution name must not be changed.
  • The solution package should not include any of SharePoint installed files.
  • Referenced assemblies should not be set to copy local = ‘true’.
  • All prerequisites must be communicated to the customer and pre-installed as stand-alone components for easier administration.

Tools for Building the Solution:

Tools for Quality Assurance:

  • Use FXCop for identifying and fixing performance and security issues in source code.
  • Use the CAT.NET to help identify security issues in the solution source code.
  • Use StyleCop to identify code style and naming conventions issues.
  • Use the SPDisposeCheck tool

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.

Quality Assurance:

Release to Customer:

  • Provide an Installation Guide which contains the following items:
    • 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.