Best Practices for SharePoint Solution Deployment
Salaudeen Rajack
SharePoint Solution PackagesWhat is a solution package?– A solution package is a distribution package that delivers your
custom SharePoint Server development work to the Web servers or the application servers in your server farm.
– Use solutions to package and deploy • custom Features• site definitions, Master Pages• Application Pages, Custom Pages, layout pages• Templates, Images• Web Parts, User Controls• Cascading style sheets• Event Receivers, Workflow Activities, Workflow Assemblies• Global Resources (.resx files)• Policies and assemblies.
– WSP files are just CAB file with .WSP extension. – Templates and/or components in an installable unit– Package that contains metadata (manifest.xml)
Master pages, layouts, CSS, images, scripts – Developer Reference
• Into a library inside your site collection
– Can be referenced by ~site, ~sitecollection and ~masterpage
– Only available within the site collection– Too many site collection makes it harder to update these
files– Updatable through the web interface
• Into the _LAYOUTS folder
– Can be referenced by path to folder– Available for every Sharepoint website in farm– One place for easy updating these files– Only updatable directly on the server– All web applications on the server share this folder
• Site Customizations
– Changes to one particular site recorded in content DB
– Done using the browser or the SharePoint Designer– Easy to do but hard to reuse
• Solution Development
– Creation of reusable templates/components– Templates/components installed on Web server– Development based on Visual Studio projects– Project source files checked into source code control– Projects can be moved through staging to
production
Site customizations Vs Solutions Development
Solution Life Cycle
Tools• WSPBuilder
– Creates SharePoint Solutions files based on a folder structure
– Deploy solutions• SharePoint Installer
– Creating user friendly installation and deployments for SharePoint 2007 solutions
• VSeWSS 1.2
– Visual Studio 2008 extensions• STSDEV
– Generate Visual Studio project files and solution files • STSADM
– 184 operations through command line on the web server– Custom extensions possible
Deploying SharePoint Solutions
• Add .WSP to the solution store– Via command line using STSADM– Via object model
• Deploy to all or individual Web Applications– Via Central Administration
(solution mgmt)– Via Command-line– Via Object Model
Stsadm –o addsolution –filename mypackage.wsp
Front-End Web Servers
Solution Store
stsadm -o deploysolution -name mypackage.wsp –local -url IISWebApp
Retracting SharePoint Solutions• Retracting is removing the solution components from the servers where
it was deployed
• Be aware:
– Post-retracting actions can be necessary (e.g. Web Parts)
– Once instances have been created from schemas (e.g. List templates), retracting a solution is not adviced. Leave the solution on the server but hide the Features making the solution components available
MySolution.wsp(v 1.0)
MySolution.wsp(v 2.0)
MySolution.wsp
Stsadm –o addsolution –filename mysolution.wsp
Deploy Solution
Stsadm –o upgradesolution -name mysolution.wsp –filename mysolution.wsp –immediate -allowgacdeployment
SolutionID must bethe same!
Upgrading Solutions
•Feature-based Components
•Custom Application Page•Site Page Templates•Master Pages•Web Parts•Site Columns and Content Types•Custom List and Document Library Definitions•List-based Event HandlersCustom Workflows
•Components creating without using features
•Custom Field Types•Site Definitions
WSS Component Development
Features
• A building block for creating SharePoint solutions– A unit of design, implementation and deployment
• Features can contain elements– e.g. menu items, links, list types and list instances
• Features can contain event handlers– You can add any code which used WSS object model
• Features can depend on other Features• Features can be stapled
Solution deployment• “Featurize” your custom development
– Any SharePoint element– Changes in your web.config– Copying files to specific web folders
• Deploy features and other assets by WSP Solution package• Your development machine does not go into production• Use a buildserver• Always test with different set of browsers (level 1 and level 2)• Watch out for rights
• This is where many of your development files need to be deployed
– Most files go into templates directory
The Root files directory:
Web Service files
GLOBAL .RESX files
Application Pages
User Controls
Features
Field*.xml files
Site Definitions
Images
Admin Pages
Whats inside manifest.xml
MyStuff.wspMyStuff.wsp
manifest.xml
Other StuffTemplates/components
• Defines Solution properties and contents
A Sample Manifest.xml file
• Use WSP Builder (codeplex)• Can done using MAKECAB.EXE also
– Requires .DDF input file
Solution Package Build ProcessSolution Package Build Process
InputDDF File MAKECAB.EXEMAKECAB.EXE
OutputWSP File
Building the .WSP file
MyStuff.wspMyStuff.wsp
• DDF file must build proper folder structure– Prefer .Set DestinationDir instruction
DDF file – closer look
.WSP Install.WSP Install
(1) Solution Package Installation– .WSP file is copied to ConfigDB
(2) Solution Package Deployment– .WSP pushed out to Web servers– Usually requires IIS Reset operation– Done in production farm in off hours
REM - Deploy Solution Package MyStuff.wsp to Web servers in farm%STSADM% -o deploysolution -name MyStuff.wsp -immediate
REM – force batch file to run timer job synchronously%STSADM% -o execadmsvcjobs
REM - Install CustomApplicationPages.wsp in WSS Solution Package Store%STSADM% -o addsolution -filename MyStuff.wsp
REM – force batch file to run timer job synchronously%STSADM% -o execadmsvcjobs
WSP ConfigDB
.WSP Deploy
WFE
WFE
WFE
ConfigDB
WSP
Two Phases of WSP Deployment
• Central Admin provides some control– Allows you to see and deploy .WSP files– Does not provide a way to install .WSP files
Solution Management
• Central Admin allows some inspection
Solution Package Properties
• Best Practices– Create solution-specific directory in LAYOUTS– Use code-behind with DLL installed in GAC– Adding a complimentary feature for
navigation
Application Pages - Best Practices
• Best Practices– Use file-based templates for page creation– Add SafeControl setting when using custom
controls– Deploy .ascx files into CONTROLTEMPLATES – Clean up during feature deactivation
Custom Site Pages
• Best Practices– Deploying custom field type using a .WSP– Avoiding naming conflicts with .ascx files
Field Types
• Best Practices– Adding SafeControl entries using manifest.xml– Deploy feature to push .webpart files into Web
Part gallery
Web Parts
Web Part inside the WSP• Do not use any code in your Web Part• Always load an UserControl
– Use the ControlTemplates folder– Put the logic into the control– Code and design should be separated
• Put only properties in your Web Part• Two namespaces
– System.Web.UI.WebControls.WebParts– Microsoft.SharePoint.WebParts
Permissions• Your code runs with permissions of the logged on user• Set up proper testing for Permissions
– Especially for anonymous internet facing sites– I always use Firefox since it does not log me on
• Coding & Elevation
– Impersonation– SPSecurity.RunWithElevatedPrivileges
Typical batch files for Install/Retract solutions
• Install.bat• stsadm.exe -o addsolution -filename
MyListSolution.wsp• stsadm.exe -o deploysolution -name
MyListSolution.wsp -local
• Retract.bat• stsadm.exe -o retractsolution -name
MyListSolution.wsp –local• stsadm.exe -o deletesolution -name
MyListSolution.wsp
• Best Practices– make sure WSP files are documented -just a few lines to tell what the solution
contains and what it does (makes it easier when you need to debug what caused your farm to become unstable)
– make sure dependencies between WSP files are documented – require that upgrade scenarios have been thought into the features you are
about to install (often this will include callout code that handles feature deactivation)
– create a baseline performance indication of your farm that you update each time you deploy new solutions and features to monitor performance degradation
– use batch files scripts to deploy your packages to make deployments consistent across environments (dev-test, integration-test, pre-prod, prod)
– Don't accept debug mode build assemblies! – suggest developers do code review before releasing code – Make sure, your WSP has un-installation module in place.
General Guidelines
Check List• Verify the Scope of the solutions • Make sure "UpgradeSolution" swith is used, when deploying next version • Make sure, files are deployed to the right directory• Verify the structure of the Manifest.xml file• Check for naming conflicts with files (eg. Company name - component-
version) • Make sure WSP files are well documented. • make sure dependencies between WSP files are documented
Don't accept debug mode build assemblies! • Ensure that new solutions have a unique GUID in the Farm Ensure that
the new solution version number is incremented (format V#.#.#) • The solution package should not include any of SharePoint installed files. • All source code must be under a proper source control All releases,
internal builds must have proper labels on source control.
Resources• Best practices resource center for SharePoint 2007
http://technet.microsoft.com/en-us/office/sharepointserver/bb736746.aspx• Patterns and practices SharePoint guidance
http://www.codeplex.com/spg• Best practices for SharePoint guidance
http://msdn.microsoft.com/en-us/library/dd203468.aspx• SharePoint Deployment Planning Services
https://iwsolve.partners.extranet.microsoft.com/SDPS/• Downloadable book: Design and build sites for Office SharePoint Server 2007
http://go.microsoft.com/fwlink/?LinkId=110087• Other resources such as
http://www.codeplex.com / http://www.dutchsug.nl / www.microsoft.com/sharepoint
Recommended
