Some easier than others Definition vs. Instance Site Column <Field> SPSite, SPWeb Content Type <ContentType> SPSite, SPWeb, SPList Web Part <WebPart> WP Gallery, Instances on pages List Template SPSite, SPWeb, Instances at SPWeb
Some easier than others Module (Page Layout, Master Page, Style sheets) As long as not ‘customised’ Renaming files
“OLD SKOOL” Imperative in-place upgrade Deactivate/Activate -> “if column missing add it” Deactivate/Retract/Remove/Add/Deploy/Activate Won’t work if in USE! Field Content Types – blocks delete Web Parts out of gallery and Web Part Instances List Templates – removes but breaks List instances Workflow – removes assembly, breaks Workflow instances New Feature - Stapling PowerShell
One farm many feature versions active SITE A SITE B SITE C SPDevWiki V126.96.36.199 SPDevWiki V188.8.131.52 SPDevWiki V184.108.40.206 SPDevWiki V220.127.116.11 SPDevWiki V18.104.22.168 SPDevWiki V22.214.171.124 SPDevWiki V126.96.36.199 SPDevWiki V188.8.131.52
Upgrading features declaratively Version attribute not just for show ;-) Not set by default in XML so uses 0.0.0.0 ActivationDependencies can specify version UpgradeActions element VersionRange with Begin & End versions MinimumVersion ApplyElementManifest AddContentTypeField MapFile
TIPS Don’t forget to change definition as well do upgrade ALWAYS quit PowerShell when rebuilding WSP Or use different names for WSP If CustomUpgradeAction fails, doesn’t upgrade feature Will leave things “half baked” – defensive coding Adjust ULS logs to see messages ‘Feature Infrastructure’, ‘Fields’, ‘General’
What to watch - Definitions Copy definition, create new one, hide old version List Templates Workflow Site Definitions or Feature stapling
What to watch - instances Web Parts Imperatively modify properties Assembly upgrade List Instances Incrementally upgrade Workflows Assembly upgrade on existing activities Changing what activities exist on current instances “You’re on your own soldier”
SANDBOXED SOLUTIONS Slightly different! Upgrade button for Sandboxed Solutions On upgrading a Solution All Features are upgraded automatically!
Solution version Defined by having new wsp name e.g. SPDevWiki_v184.108.40.206.wsp and SPDevWiki_v220.127.116.11.wsp Sandboxed Solutions Deploying different versions to different Site Collections in Farm Supported in Farm Solutions Easy way to identify what version in different Farms no other way of identifying solutions only keeps most recent
Assembly versions New Assembly Version Workflow instances + Web Part instances Will remove old version from GAC breaking old Web Parts Use Binding Redirect if not worried about old assembly version – if so why do it in the first place? Assembly Versioning broken in Sandboxed Solutions
Feature upgrade object model QueryFeatures method (4 overloads) GuidfeatureId GuidfeatureId, boolneedsUpgrade GuidfeatureId, Version featureVersion SPFeatureScope scope, boolneedsUpgrade Available from SPWebService(Farm), SPWebApplication, SPContentDatabase & SPSite
Versioning strategies Main Goal Identify which versions are across farm Assembly version and Feature versions will diverge Release notes needed! Stick with one approach Major.Minor.Build.Revision Change severity (breaking/major/minor) Shipping/non-shipping (product orientated) Incorporate sprint/iteration Incorporate changeset number Other crazy approaches!
How can I prepare 2007 code? Start versioning your features – default 0.0.0.0 <SharePoint:UIVersionedContentUIVersion=“4”> Deprecated API’s Binding redirects VSeWSS -> VS2010 supported WSPBuilder/STSDev/STSADM/custom -> manual
Visual Studio 2010 add-in TechNet walkthrough for building VSIX add-in http://msdn.microsoft.com/en-us/library/ee256698.aspx Tommy Segoro (WA, AUS) Completed code sample http://vs2010spupgrade.codeplex.com/
REFERENCES Recorded webinar and scripts from session wss.made4the.net My Delicious Links