410 likes | 524 Views
Packaging Your Advanced SharePoint Customizations. Neil Iversen Inetium http://justaddcode.com. Solution Basics. At its core, a solution pushes files around The File Bus of SharePoint ‘Farm Safe’ – Works across Front Ends Deployed to the Farm. Solution Life Cycle – High Level. Features.
E N D
Packaging Your Advanced SharePoint Customizations Neil Iversen Inetium http://justaddcode.com
Solution Basics • At its core, a solution pushes files around • The File Bus of SharePoint • ‘Farm Safe’ – Works across Front Ends • Deployed to the Farm
Features • Deployable unit of functionality • Used to customize SharePoint • Extensively used by SharePoint itself • Stored in the Hive • 12\TEMPLATE\FEATURES • Each feature in its own directory
Types of Features • Content Type • Custom Action • Delegate Controls • Events • Feature Stapling • Field • Lists (Templates and Instances) • Module • Workflow
Why do I need this fancy packaging? • You need something that isn’t available in the OOB Features • The OOB Features do/don’t do something you need • You are deploying something outside of SharePoint • And you still care about change control
Individual Developer Environments • Developers build functionality into features/solutions Developer Merge Developer Alice Developer Bob Developer Charlie Stage Prod
Feature Receivers • Executes code when the state changes • Key to our ability to make drastic changes • “If you can code it you can do it” • Allows for extremely powerful code to get added • While still being easily deployable • Overrides • FeatureInstalled, FeatureUninstalling • FeatureActivated, FeatureDeactivating • Example • <Feature Id="0a7e1ca9-ee71-4407-80a0-b5b57f4f6f5d" Title=“My Feature Reciever" Scope="Site" ReceiverAssembly=“MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=e35a4d2663eae0ae" ReceiverClass=“MyAssembly.MyFeatureReciever" xmlns="http://schemas.microsoft.com/sharepoint/">
Feature Receivers – Getting Context • Getting Context • Retrieving the Current Scoped Object • SPFeatureReceiverProperties • SPFeatureReceiverProperties.Feature.Parent • Cast to the appropriate type • Scope: Web • SPWeb web = (SPWeb)properties.Feature.Parent; • SPSite site = (SPSite)properties.Feature.Parent
Scopes • Farm • Web App • Site • Web Indexer Database WFE B WFE A Extranet WFE http://sitecollection http://external http://sitecollection/deptA http://external/clientA http://sitecollection/deptB
Feature Receivers - Debugging • Based on Deployment/Activation Method • Stsadm • Runs as currently logged in user • Debug/Console.WriteLine • System.Diagnostics.Debugger.Launch(); • Web Interface • Runs as App Pool user • Need to use logger (EventLog, or some Logging code) • Attach to w3wp.exe • DLL Deployment • Overwrite Existing DLL • iisreset • stsadm –o activatefeature -force
Testing Your Code • Unit Testing Features • Pretty straight forward if you Develop on a SharePoint environment • Probably want to ignore your abstraction violations (SharePoint mocks are tough) • Always test Farm/Scope safety • Need a multi server environment • Can you make it part of your build?
Feature Object Model • SPFarm.FeatureDefinitions • SPSite.Features • SPWeb.Features • SPFeature • SPFeatureDefinition
Feature Properties • Configuration for your Feature • Allow different values for Dev/Test/Prod • Combine with scoped property bags to set configurations • Example <Properties> <Property Key=“MyKey" Value=“123" /> <Property Key=“DBServer" Value=“prodsql001" /> </Properties>
Manually Activating Features • Why? • Evade chaining restrictions (at your own peril) • Working with Hidden Features • Manage Stages of a Site with a Web Part • Creating a ‘Suicide Feature’
Manually Activating a Feature • Get your Context • Ex: SPWeb • Find the Feature Collection • Ex: SPWeb.Features • Find the Feature’s Guid • Ex: Guid featureGuid = new Guid(“0a7e1ca9-ee71-4407-80a0-b5b57f4f6f5d”) • Activate! • Ex: SPWeb.Features.Add(featureGuid)
Feature Properties • Configuration for your Feature • Allow different values for Dev/Test/Prod • Combine with scoped property bags to set configurations • Example <Properties> <Property Key=“MyKey" Value=“123" /> <Property Key=“DBServer" Value=“prodsql001" /> </Properties>
Dependencies and Features • Your Feature might need to assume another feature is already active • Make several smaller features, then wrap them into a single feature that is dependant on them • Dependencies can only be one level deep • Example • <ActivationDependencies> <ActivationDependency FeatureId="52890518-036f- 4027-babd-f4c7df3ee429" /> <ActivationDependency FeatureId="6d276cfc-1c84- 46cc-8566-500e66213e06 " /> </ActivationDependencies>
Dependency Limitations • Feature Chains • Limited to one visible feature • Dependencies can’t be triggered at a higher scope • Ex: Farm Feature can’t depend on a Web Feature • Features can’t be automatically activated at different scopes • Ex: Web Feature can’t activate a Farm Feature
Feature Dependency Dependant Parent
Hidden Feature - Deactivate 3. 1. 2.
Putting it Together • Problem: Modifying the web.config in a Farm Safe manner • Solution: SPWebConfigModification and Features • SPWebConfigModification is Farm Safe • Scoping does become an issuee
Getting a little crazy • What about non-SharePoint assets? • Databases, other web sites, … • Is there an advantage? • Depends on reason for creating the Feature • Most common is Devs can’t touch Prod
Other Interesting Approaches • Manually Deploy across a Farm • Create your own Timer Jobs • Manually add them to the different WFEs • PowerShell ‘Feature’ • Execute PowerShell via a Feature • PowerShell v2 Scripts • Has ability to execute remote commands
Your Feedback is Important Please fill out a session evaluation form and either put them in the basket near the exit or drop them off at the conference registration desk. Thank you!
Thanks! Neil Iversen Inetium http://justaddcode.com