Managing the SharePoint Application Lifecycle – beyond

version 1.0.0.0PART 2

DEV108

Chris O’Brien - MVP

Chris O’Brien, MVP, MCSD.Net, MCTS www.sharepointnutsandbolts.com Twitter: @ChrisO_Brien

Hands-on developer Author of ALM chapter in MVP book Creator of Content Deployment Wizard tool Regular speaker at UK user group

Last time..

Upgrading a SharePoint application

• SP2010 upgradable Features• How to version a Feature• Using code/XML to upgrade

Initial build • Feature framework changes• Leveraging WSP import

Today’s focus

Upgrading a SharePoint application

• How to upgrade different artifacts

• Changes to WSP framework

• Assembly versioning in SP2010

• Versioning recommendations

Recap – Feature upgrade

Versioning/upgrading Features

Version attribute now has a purpose! Define what should occur in 1.0.0.0-2.0.0.0

UpgradeActions element XML – some new XML for common

scenarios Code – specify method/parameters in

CustomUpgradeActions element– New FeatureUpgrading method – add logic here

Feature upgrade XML

ApplyElementManifests Integrate new artifacts into existing Feature Sometimes all you need!

AddContentTypeField Add columns to content type

MapFile Repoint a file to new location on filesystem

(uncustomized files only)

Demo

UPGRADING A FEATUREUpdating functionality

Artifact upgrade

Upgrade - ‘provisioned’ artifacts

Typically must use API:

Artifact Upgrade

Field, list instance, view, content type binding, document convertor

• Use API

‘Standard’ cases

Content type • Use AddContentTypeField• Use API

Module (file) • Uncustomized: • Overwrite file on

filesystem• Use MapFile

• Customized: • Overwrite file in

library

Upgrade - ‘declarative’ artifacts

Artifact Upgrade

Control (delegate control), CustomAction, Feature staple, workflow template

• Update XML

Typically update file on filesystem:

‘Standard’ cases

List definition • Update schema.xml (carefully!)• Deploy new list definition, mark

old as hidden

Site definition • New sites - staple new Feature• Existing sites – activate Feature

(script?)• OR upgrade existing Feature

‘Upgrading workflows

Special considerations Deserialization errors after upgrade

Typically ensure new instances use new SPWorkflowAssociation to new assembly– Allow running instances to complete using old

assembly

WSP framework

Solution framework changes

Resource files Resx files can now target

App_GlobalResources folder

Solution dependencies But not solution receivers

Assembly binding redirects

Dealing with shared assemblies

Solution dependencies: Does not deploy dependent solution Only checks at deployment time – possible

to retract a depended on solution Redirects help for versioning assemblies:

Version numbers stored everywhere! Redirect = one place to update

Demo

ASSEMBLY VERSIONINGUpdating functionality

Versioning strategies - ?.?.?.?

Assembly versioning – tracing back: Main thing is to increment in some way Common plans - Major.Minor.Build.Revision:

– Change severity (breaking/major/minor) – Shipping/non-shipping (product-oriented)– Incorporate sprint/iteration– Incorporate changeset number– Other custom

Consider ‘File version’ for internal versioning

Versioning strategies - ?.?.?.?

Feature versioning: Main purpose - identify which version is

where across farm Use similar principles as assemblies:

– Increment major for large/new release changes

Assembly/Feature versions will diverge Keep release notes to track

Summary

Now have standardized framework for upgrading applications New XML e.g. AddFieldToContentType Implement code in FeatureUpgrading event

Use the new capabilities! WSP import Solution dependencies for shared

assemblies

Closing thoughts

If you didn’t before, now is the time to do versioning! Assemblies -> AssembyBindingRedirect Features -> Feature upgrade code/XML

Some extra considerations, but big benefits for non-trivial apps

Thank you for attending!