Packaging Your Advanced SharePoint Customizations - PowerPoint PPT Presentation

Packaging Your Advanced SharePoint Customizations

Neil Iversen

Inetium

http://justaddcode.com

• At its core, a solution pushes files around
• The File Bus of SharePoint
• ‘Farm Safe’ – Works across Front Ends
• Deployed to the Farm

• 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

• Content Type
• Custom Action
• Delegate Controls
• Events
• Feature Stapling
• Field
• Lists (Templates and Instances)
• Module
• Workflow

• 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

• 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/">

• 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

• 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

• 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

• 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?

• SPFarm.FeatureDefinitions
• SPSite.Features
• SPWeb.Features
• SPFeature
• SPFeatureDefinition

• 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>

• 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’

• 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)

• 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>

• 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>

• 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

Dependant

Parent

1.

2.

2.

1.

3.

1.

2.

• Problem: Modifying the web.config in a Farm Safe manner
• Solution: SPWebConfigModification and Features
• SPWebConfigModification is Farm Safe
• Scoping does become an issuee

Not for the faint of heart!

• 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

• 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

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!

Neil Iversen

Inetium

http://justaddcode.com