Nell’iperspazio con Rocket: il Framework Web di Rust!
Deep dive into feature versioning and upgrade support in SharePoint 2010
1. Deep dive into feature versioning and upgrade support in SharePoint 2010 Jeremy Thake
2. Jeremy Thake Enterprise Architect since April ’11 at AvePoint SharePoint MVP since July ’10 Co-Founder of NothingButSharePoint.com Speaker at MS TechEd 2009/10, SPC 11 Gplus.to/jthake @jthake
9. 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
10. Some easier than others Module (Page Layout, Master Page, Style sheets) As long as not ‘customised’ Renaming files
11. “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
13. One farm many feature versions active SITE A SITE B SITE C SPDevWiki V1.0.0.0 SPDevWiki V3.0.0.0 SPDevWiki V2.0.0.0 SPDevWiki V3.0.0.0 SPDevWiki V3.0.0.0 SPDevWiki V1.0.0.0 SPDevWiki V2.0.0.0 SPDevWiki V3.0.0.0
14.
15. 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
24. UPGRADEactions Imperative Provide assembly & class in UpgradeActions CustomUpgradeActionss element provides Name and Parameters Fires FeatureUpgrading event receiver
28. 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’
29. What to watch - Definitions Copy definition, create new one, hide old version List Templates Workflow Site Definitions or Feature stapling
30. 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”
31. SANDBOXED SOLUTIONS Slightly different! Upgrade button for Sandboxed Solutions On upgrading a Solution All Features are upgraded automatically!
32. Solution version Defined by having new wsp name e.g. SPDevWiki_v1.0.0.0.wsp and SPDevWiki_v2.0.0.0.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
33. 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
34. Feature upgrade object model QueryFeatures method (4 overloads) GuidfeatureId GuidfeatureId, boolneedsUpgrade GuidfeatureId, Version featureVersion SPFeatureScope scope, boolneedsUpgrade Available from SPWebService(Farm), SPWebApplication, SPContentDatabase & SPSite
35. 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!
36. 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
40. 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/
In 2007 provisioning artefacts and then upgrading them was like head butting a brick wall. It’s quick and easy to create these things in the Web UI in one environment, and extremely easy to add new Site Columns to existing Content Types. Or modify Web Part properties.But when you have 10 Site Collections with 20 Content Types and have to modify them in Development, Test and Production. This is tedious for every promotion of a change. This is why we do development over configuration.
Some things are easier than others to replace.Definitions vs InstancesMost are not aware that although you define a Content Type at the Site Collection level, if you create a List in a sub site and attach a Content Type to the List it creates an Instance which has a “link” back to the definition. The same is true of List Templates, although this works slightly different again in that once a List Instance is created, if you modify the List Template the changes are promoted to the List Instance. This is by design, you would need to imperatively update each List Instance. This is why it is encouraged to use Content Types because at least you can push down changes to Fields that way.Pushing Changes DownIn the UI you can change the definition and it pushes the changes down to these instances, but if you do it imperatively in code you have to be careful. It is unsupported to change Content Type Definitions declaratively.Module PagesModule Pages in a Site Collection will reference the file deployed in the Feature within the SharePoint Root (hive), and as long as they are not customised, will automatically take the updated version.
Module PagesModule Pages in a Site Collection will reference the file deployed in the Feature within the SharePoint Root (hive), and as long as they are not customised, will automatically take the updated version.
Deactivate/ActivateThis is a common approach where you just deactivate the feature and reactive which will run the Feature Receiver code where you could imperatively “do stuff” like check columns existed on Content Types etc. to ensure that they matched the Definition in the Content Type manifest in the Feature.In most instances it will pull out the Content Type defintions etc. if they are not used and then on Activation it will provision the new updated Definition. This does not work if the Content Type is in use, which in most cases it will be.Clean upSome people will actually remove Definitions on Deactivation to clean up. Such as Content Type Definitions or even List Templates and Web Parts. Remember that when you deactivate, by default it will leave any instances deployed by Module elements e.g. Web Part Definitions and Master Pages.PowerShellIn 2007 some people used PowerShell to imperatively go through instances in each Site Collection and tweak them. Sometimes, as a Developer it was often slower to sit and work out the API to modify a Content Type compared to a few seconds in the UI. There’s snippets of code all over the web for this and we’ll have the same issues again in SharePoint 2010 although a lot of the SharePoint 2007 stuff is re usable.Don’t overuse features where you are for instance just creating a Images Library on100 sites and deploy a Solution Package with a Feature with List Instance in it. Simply recurse through the sites with PowerShell to provision it.
Feature Version actually means something in SharePoint 2010. It was unused attribute in SharePoint 2007.
#create new project#create content type based on Article#run package solutionAdd-SPSolution -LiteralPath "C:\\Users\\sp_admin\\Documents\\Visual Studio 2010\\Projects\\SharePointProject4\\SPDevWiki.ContentTypesFarmDemo\\bin\\debug\\SPDevWiki.ContentTypesFarmDemo.wsp"Install-SPSolution -Identity "SPDevWiki.ContentTypesFarmDemo.wsp" -GACDeployment#show that farm feature has it at 1.0.0.0get-spfeature | where {$_.DisplayName -eq 'SPDevWiki.ContentTypesFarmDemo_SPDevWiki.ContentTypesFarmDemo' } | select DisplayName, Version#show that feature doesn't exist at Site Collection yet$site = get-spsite "http://sp2010rtm:99"$feature = $site.Features | where {$_.DefinitionId -eq 'cc9f1e0b-44ac-4a75-880c-768576cfd4eb' }$featureEnable-SPFeature -Identity "SPDevWiki.ContentTypesFarmDemo_SPDevWiki.ContentTypesFarmDemo" -Url "http://sp2010rtm:99"#show that feature does exist at Site Collection$site = get-spsite "http://sp2010rtm:99"$feature = $site.Features | where {$_.DefinitionId -eq 'cc9f1e0b-44ac-4a75-880c-768576cfd4eb' }$feature#Add UpgradeActions for new Site column on Content Type#add a ApplyElementManifests#add the xml snippet#create the new Manifest File - highlight that field isn't a new SPI#Increment Feature Version from 1.0.0.0 to 2.0.0.0Update-SPSolution -Identity "SPDevWiki.ContentTypesFarmDemo.wsp" -LiteralPath "C:\\Users\\sp_admin\\Documents\\Visual Studio 2010\\Projects\\SharePointProject4\\SPDevWiki.ContentTypesFarmDemo\\bin\\debug\\SPDevWiki.ContentTypesFarmDemo.wsp" -GACDeployment#Show how feature is updated in Farm - show it doesn't show up updated versionget-spfeature | where {$_.DisplayName -eq 'SPDevWiki.ContentTypesFarmDemo_SPDevWiki.ContentTypesFarmDemo' } | select DisplayName, Version#Need to shut down PowerShell to reflect the change here!get-spfeature | where {$_.DisplayName -eq 'SPDevWiki.ContentTypesFarmDemo_SPDevWiki.ContentTypesFarmDemo' } | select DisplayName, Version#Show how Version isn't updated on site yet$site = get-spsite "http://sp2010rtm:99"$feature = $site.Features | where {$_.DefinitionId -eq 'cc9f1e0b-44ac-4a75-880c-768576cfd4eb' }$feature#Run the upgrade$feature.Upgrade($false);#show that feature has upgraded on Site Collection now$feature#show Content Type updated showing new field#now show feature installed on new Site Collection that hasn't had it enabled beforeEnable-SPFeature -Identity "SPDevWiki.ContentTypesFarmDemo_SPDevWiki.ContentTypesFarmDemo" -Url "http://sp2010rtm:81"#show ContentType re-appears and that feature is now on 2.0.0.0$site = get-spsite "http://sp2010rtm:81"$feature = $site.Features | where {$_.DefinitionId -eq 'cc9f1e0b-44ac-4a75-880c-768576cfd4eb' }$feature#show that content Type does not have the new field#Run the upgrade$feature.Upgrade($false);#Show that content Type still does not have the new field$feature#Raise importance that you still need to add the stuff to the base content type too#Upgrade is purely to incrementally upgrade instances!#add <FieldRef /> to contenttypeUpdate-SPSolution -Identity "SPDevWiki.ContentTypesFarmDemo.wsp" -LiteralPath "C:\\Users\\sp_admin\\Documents\\Visual Studio 2010\\Projects\\SharePointProject4\\SPDevWiki.ContentTypesFarmDemo\\bin\\debug\\SPDevWiki.ContentTypesFarmDemo.wsp" -GACDeployment#Show that feature now has the new field#now add a feature receiver and add the code snippets#copy the feature assembly info into the upgrade feature assembly bits in properties window#add <CustomUpgradeAction Name="Upgrade6.0.0.0To7.0.0.0" /> to new VersionRangeUpdate-SPSolution -Identity "SPDevWiki.ContentTypesFarmDemo.wsp" -LiteralPath "C:\\Users\\sp_admin\\Documents\\Visual Studio 2010\\Projects\\SharePointProject4\\SPDevWiki.ContentTypesFarmDemo\\bin\\debug\\SPDevWiki.ContentTypesFarmDemo.wsp" -GACDeployment#close powershell#run$site = get-spsite "http://sp2010rtm:99"$feature = $site.Features | where {$_.DefinitionId -eq 'cc9f1e0b-44ac-4a75-880c-768576cfd4eb' }$feature#note that if this fails, stays at existing feature version but antying it's managed to do declaritively and imperatively will be done and not rolled out (ARGHHH!)$feature.Upgrade($false);$feature#not used#remove featureDisable-SPFeature -Identity "SPDevWiki.ContentTypesFarmDemo_SPDevWiki.ContentTypesFarmDemo" -Url "http://sp2010rtm:99"#show it gone from Content Types list#now remove v2.0.0.0 in fullUninstall-SPSolution -Identity "SPDevWiki.ContentTypesFarmDemo.wsp"Remove-SPSolution -Identity "SPDevWiki.ContentTypesFarmDemo.wsp"#now add v3.0.0.0 solutionAdd-SPSolution -LiteralPath "C:\\Users\\sp_admin\\Documents\\Visual Studio 2010\\Projects\\SharePointProject4\\SPDevWiki.ContentTypesFarmDemo\\bin\\debug\\SPDevWiki.ContentTypesFarmDemo.wsp"Install-SPSolution -Identity "SPDevWiki.ContentTypesFarmDemo.wsp" -GACDeploymentEnable-SPFeature -Identity "SPDevWiki.ContentTypesFarmDemo_SPDevWiki.ContentTypesFarmDemo" -Url "http://sp2010rtm:99"
http://technet.microsoft.com/en-us/library/ee906565.aspxNote: You should probably start a new instance of PowerShell after each time you build, otherwise the actions you perform may be run against an outdated version of your assembly from the GAC. The same thing sometimes applies to Visual Studio deployment, for instance if one solution refers to an assembly in another solution!
(get-spweb http://sp2010rtm:99/).Features | where {$_.DefinitionId -eq '7cd284c9-b998-457b-b782-4473744b7daf' }get-spfeature | where {$_.DefinitionId -eq '7cd284c9-b998-457b-b782-4473744b7daf' } | select DisplayName, Version
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spsite.queryfeatures(office.14).aspxReturns SPFeatureQueryResultCollection Depending on at what level you query the returned features could cover various scopesSPWebServiceFinds all instances of the feature with given id that require upgrade in the farm. All scopes of features (Farm, Web Application, Site collection, Web) are supported.SPWebApplicationFinds all instances of the feature with given id in all content databases. Web app/site collection/web scoped features are supported.SPContentDatabaseOverloads of QueryFeatures function of this class find site and web scoped features in content database that conform to filtering criteria. Returned collection is ordered with regard to web hierarchy. Parent web features goes before child web features and traversal of the tree is done in depth-first manner.SPSiteOverloads of QueryFeatures function of this class find web scoped features in site collection that conform to filtering criteria. Returned collection is ordered with regard to web hierarchy. Parent web features goes before child web features and traversal of the tree is done in depth-first manner. Overloads of QueryFeatures function of this class will be available in Client OM.