[Road to SharePoint 2010] Repackage Your Developments for a Better Tomorrow

Today I want to comment on what should you take care of when preparing your SharePoint 2007 customizations for the 2010 world.

The Good Guys

“The Good Guys” are those customizations that should behave well when upgraded.

Features

The existing SharePoint 2007 features will (hopefully) upgrade with no fuss. By looking on the disclosed SP2010 SDK, one can see that the features will be able to “upgrade” themselves, invoking SPFeature.Upgrade method. This call will run the code you specify in the upgrade feature UpgradeReceiverAssembly property. This will probably be a special feature that will upgrade the rest of the features in a given scope.

This code from the SDK illustrates the issue:

//  Represent the id of the feature we want to upgrade.  

Guid featureId = new Guid("1B006A62-7B92-475c-A2E5-A1CF03EE0887");  

//  Get the default Web service in the farm.  

SPWebService webService = SPFarm.Local.Services.GetValue<SPWebService>("");  

//  Get all feature instances with the specified ID that require upgrade.  

SPFeatureQueryResultCollection features = webService.QueryFeatures(featureId, true);  

//  Get a features enumerator.  

IEnumerator<SPFeature> featureEnumerator = features.GetEnumerator();  

while (featureEnumerator.MoveNext())  

{  

    //  Get current feature.  

    SPFeature feature = featureEnumerator.Current;  

    //  Upgrade the current feature.  

    Console.WriteLine("Upgrading feature {0} with id {1}.",   

                      feature.Definition.DisplayName, feature.DefinitionId);  

    Console.WriteLine("Feature Version Before Upgrade: {0}", feature.Version);  

    feature.Upgrade(false);  

    Console.WriteLine("Feature Version After Upgrade: {0}", feature.Version);  

}

Furthermore, it seems that the features will be properly versioned (at least). Again, I quote the SDK:

The value of this property can be different from the value of the Version property of the underlying feature definition. For example, you might deploy a feature that uses a feature definition with a version number of 1. At that point, both the feature instance and the feature definition have the same version number. Suppose that subsequently you modify the feature definition and re-deploy it with a version number of 2. Now the feature definition is version 2, but the feature instance remains version 1. That indicates that the feature instance needs to be upgraded. You need to run feature upgrade code to move the version of the feature instance from 1 to 2.

Solutions (WSP packages)

This recommended way of packaging the features and enhancements will hopefully upgrade straight-forward. Even more, it seems that it will be possible to “sandbox” a solution to limit its visibility to just a single site collection, without affecting the rest of the farm. The SDK mentions a SPUserSolution class (“This class allows solutions to be uploaded at the site collection scope and run in a sandbox.”).

Site Definitions

According to the STSADM preupgrade check operation, custom site definitions will have to be upgraded in-place with a Upgrade Definition File (an XML file, for sure). Hopefully, it won’t be a nightmare. Watch for a not-yet-released KB article 954761 that should explain it.

The Bad Guys

“The Bad Guys” are those customizations that you will have to rewrite or repackage in order to make them upgradeable.

Custom CAML and Ad-hoc Views

There’s new guy in town for list views in SP2010: XSLT. This standard format will replace the mutant CAML when it comes to defining the view rendering the list items. However, it comes with a price. The preupgradecheck tool will warn you which of your custom views will not be upgraded. You could leave it in CAML and SharePoint 2010 will render it well, but you will lose the new features of the XSLT-based views such as conditional formatting or SharePoint Designer 2010 customization support.

The tools mentions that “A list view using custom Collaborative Application Markup Language (CAML), a list view not associated with a Feature, or a list view associated with a custom Feature, will not be upgraded to the new XSLT-based list view”.

Custom CAML-Rendered Fields

Another CAML to XSLT victim. The custom fields that use CAML in its RenderPattern will not be upgraded to XSLT fields.

Custom Workflow Action Types

A minor issue, this one. You will have to keep a copy of your web.config and manually restore your custom workflow activity types defined in <authorizedType> tags, as they will be replaced with the new type versions.

Site and List Templates (STP files)

If you are the happy end-user that saves lists and sites for reuse as STP template files, bad news. STP files won’t be supported in SP2010, as they were present in SharePoint 2007 only to provide you with backward-compatibility with SharePoint 2003. You will have to rewrite them as site or list definitions. You can use a tool like SharePoint Solution Generator (part of the WSS 3.0 SDK) to reverse-engineer an existing site or list into a definition and then fine-tune them by hand.