2010 SPWebConfigModifications Applied

I have been noticing a few issues about SPWebConfigModifications and how they are applied.

Service Level SPWebConfigModification Applied

For instance if you have two web applications on your content service one on port 80 and other on port 8080. You can choose to have your web config modifications added to all of web applications by adding them at the SPWebService level.

SPWebService.ContentService.WebConfigModificaitons.Add(myWebConfigModification);
SPWebService.ContentService.Update();
SPWebService.ContentService.ApplyWebConfigModifications();

Advantages:

• Applied to all web applications at once
• Applied to new web applications when created
• Can be used in an auto activated farm SPFeatureDefinition

Disadvantages

• Will be applied to web applications set up by third party applications that may have special purposes which may damage these applications
• The actual SPWebModificaitons may reference specific solution based software that may not be deployed globally

Web Application Level SPWebConfigModificaitons

Alternatively it is possible to apply SPWebConfigModificaiton to a specific SPWebApplicaiton.

SPWebApplication myWebApplication;
:
myWebApplication.WebConfigModifications.Add(myWebConfigModification);
myWebApplication.Update();
SPWebService.ContentService.ApplyWebConfigModifications();

Advantages:

• Scopes to the WebApplication level SPFeatureDefinition
• Can be added to a WebApplication deployed SPSolution
• Can be added to a WebApplicaition feature that may be auto activated/deactivated

Disadvantages:

• Auto activate features always activate on create new web application.  You must make sure all necessary infrastructure pieces are in place to support the new web application as it bootstraps into IIS.

Summary:

In general the create new web application use case is often the most overlooked use case by developers.  SPWebService level SPWebConfigModificaitons will be applied to this use case.  Additionally WebApplication auto activate features will be applied to this use case.  As you program SPWebConfigModificaitons, make sure you do not block the farm administrator from creating new web applications.

Best Practices for SharePoint Solutions

Here are my personal requirements that I use for applications built on SharePoint.  I think they embody many of the best practices.

Applications should be SharePoint Solutions

·         Each application should be self contained in a single SharePoint solution .wsp file.

o   Including all DLL’s to GAC

o   Including all SafeControls

o   Including all Templates

o   Including all Features

o   Including all List and Item Schema

·         Including all WebServices  and HttpHandlers for data communication

·         Solutions should be deployable (SharePoint’s concept of an internal install) to a new Web Application or one or more existing Web Applications.

·         Solutions should not be global to the farm (SharePoint has the concept of a global solution deployment) as this prevents multiple versions of the same solution from coexisting on the farm.

·         Solutions must be visible in the Farm Solution Manager so they may be retracted from the SharePoint farm.

·         Solutions should properly clean up themselves upon a Solution retraction.

·         Solutions must play friendly with third party applications

o   Unique ID’s on all objects

o   Unique namespace within file store

o   Never override or modify built in items

o   Smart about web application configuration

·         Solution version to version compatibility must be maintained

o   If the site template needs to be upgraded

§  Never change ID or site template (no delete)

§  Add a new site template into the system with the new functionality

§  Preserve all old template definitions

·         there may be existing site content built on this template

·         there may be customer customized site templates built on this template

·         PTC partners may have built their own templates on top of existing templates

§   Mark old template definitions as hidden so that customers are discouraged from using old site definitions

§  Feature staple new features to old site definitions to add new features to previously installed sites

o   If a list definition needs to be upgraded

§  Never change ID or  remove a list definition (no delete)

·         Never remove a content type

§  add a new list definition into the system with the new functionality

§  Preserve all old list definitions

·         They may have been customized and migration is impossible without loss of customization

§  Mark old list definitions as hidden so that customers are discouraged from using old list definitions

§  Repurpose the Microsoft’s SharePoint Upgrade Schema system to upgrade old lists to new lists

o   If a feature definition needs to be upgraded

§  Never change ID or remove a feature definition (no delete)

§  Do not remove any existing element definitions

o   If a administrative object needs to be upgraded

§  Should maintain deserialization between versions

§  Override the Upgrade method in the SPPersistedObject to perform self upgrade

§  Detect old status (when deserialized) and implement the NeedsUpgrade property

§  Maintain all API’s from version to version (no delete on API)