Vesa "vesku" Juvonen

WebTemplate training materials – Lab 4 - Upgrading existing sites with feature versioning

2011-07-29T15:11:41Z

This post is lab 4 from series of training materials for WebTemplate creation and maintenance. Please check the following posts for details and other exercises. Notice that you can download full package with all required lab material from link available in introduction post. This package contains all supplementary materials and labs in word format.

WebTemplate training materials – Introduction to material
WebTemplate training materials – Lab 1 - Creation of features and basic structures
WebTemplate training materials – Lab 2 - Creation of custom navigation control and master pages
WebTemplate training materials – Lab 3 - Creation of WebTemplate for WCM site
WebTemplate training materials – Lab 4 - Upgrading existing sites with feature versioning

This particular post will concentrate on following functionalities.

Creating application page to site settings to manage feature versions
Creating feature upgrade definitions for the existing features to update existing sites

Lab 04 – Life cycle management for WebTemplate created publishing sites

The project files for this lab are in the ‘C:\Student\Labs\04_Lifecycle’ folder

Lab Objective

Lab Overview: In this lab you will update existing sites using feature upgrade definition.

Additional Resources

This lab includes the following additional resources:

Starter Files	C:\Student\Labs\04_Lifecycle\StarterFiles	Files that can be used to help complete the labs.
Source Code	C:\Student\Labs\04_Lifecycle\Solution	Completed lab source code after this exercise
Solution structure	C:\Student\Labs\Contoso.Intranet\	Solution structure started in previous exercise.

Getting Started

Notice that all code and xml elements which are meant to be copied are available as text in the Word documents. This means that if you need to copy any of those elements, it’s better to use Word document formats of these labs.

This Hands-On Lab contains a number of additional resources in fixed locations. By default, it is assumed that the base HOL directory is C:\Student and that the labs and additional resources are located under this directory.

The default working folder for this lab is ‘C:\Student\Labs\04_Lifecycle’.

Please notice that this exercise is assuming that you have environment with url http://intranet.contoso.com in your usage. If you use some alternative url, you’ll have to update scripts and use correct entries in exercises to make exercise to work properly.

Lab Setup Instructions

In the lab setup you will execute a PowerShell script that will create a new SharePoint site collection.

1. Start the Virtual Machine in Hyper-V.

2. Log on to the Virtual Machine as the local administrator with a user name of Contoso\Administrator and a password of pass@word1.

3. Open Windows Explorer and browse to the location C:\Student\Labs\Contoso.Intranet, in the folder double click Contoso.Intranet.sln to start the previously created solution structure.

This step assumes that you have already created lab 1, 2 & 3 based on the lab guidance’s, so that we can continue building up the customization package.
Notice also that package contains full source code status after lab 3 in folder C:\StudentWebTemplate\Labs\03_WCM\Solution\Contoso.Intranet - Lab 3 which you can copy as your starting point if you want to skip previous labs completely.

Exercise 1 – Creating upgrade application page

In this exercise we will create simple application page to list features, which could be upgraded. This exercise will familiarize you to feature framework object model and how we can use that for upgrading features granularly. Notice that depending on the actual deployment, you might actually want to upgrade your features using PowerShell, not by adding this kind of additional application page to site settings page also to avoid accidental upgrades by other end users.

Task 1 – Adding custom application page to solution

1. Expand Layouts folder in the Solution Explorer

2. Right click Contoso.Intranet folder and choose Add – New Item…

3. Choose Application Page template and name it as UpgradePage.aspx

4. Click Add

5. Locate ContentPlaceHolder with the Id PlaceHolderMain

6. Update place holder as in the following code snipped to include two different tables

7. Save changes

8. Open Upgradepage.aspx.cs file under the aspx file

9. Add following using statements

10. Add override for CreateChildIControls method as follows below the Page_Load method · Notice that we use QueryFeatures method to query features which can be upgraded

11. Add following DisplayFeature method below the CreateChildControls method

12. Add btnUpgrade_Click event handler below DisplayFeature method

13. Right click the SPIs folder in the solution explorer and choose Add – New Folder

14. Name folder as CustomActions

15. Right click CustomActions folder and choose Add – New

16. Choose Empty template and name it as FeatureUpgradeSiteSettings and click Add

17. Update the Elements.xml file for the custom action as follows

18. Update feature association for the just added custom action FeatureUpgradeSiteSettings so that it’s activated in the SiteMainResources feature

19. Open SiteMainResources feature and use properties window to set the version to 1.0.0.0

20. Right click Contoso.Intranet and choose Deploy

21. Move to address http://intranet.contoso.com

22. Move the Site Settings from the Site Actions

23. Click Site collection features under the Site Collection Administration

24. Activate Contoso.Intranet Site Main Resources feature

25. Move back to Site Settings page and ensure that the Site Collection Feature Upgrade link is present under the Contoso Configuration

26. Click Site Collection Feature Upgrade link is present under the Contoso Configuration to ensure that code is working properly

Page should list all activated features in site collection scope and their version
Notice that look and feel depends on which master page has been enabled for the system pages.

Task 2 – Updating features and content types

1. Move back to Visual Studio side

2. Expand SPIs folder, right click SiteColumns and choose Add – New Item

3. Choose Empty Element and name it as v2Fields

4. Update the Elements.xml as in the following code snipped

5. Save changes

6. Expand Features node and open up Contoso.Intranet Site Main Resources feature

7. Associate the v2Fields to Contoso.Intranet Site Main Resources feature. You can use packaging explorer to ensure the current associations.

This is done for new site collections, so that now added field is added automatically when new sites are created. Steps to modify existing sites will follow up later in this exercise.

8. Expand SPIs folder and ContentTypes folder in the solution explorer

9. Open Contract content type element.xml file and update the file to have the new site column referenced

This update applies for new content types and to existing sites
Notice that you shouldn’t just copy paste below entry, since Contract content type identifier depends on environment. In this step we just add the row with AdditionalDetails FieldRef entry

10. Open Page content type element.xml file and update content type to have the new site column referenced

This update applies for new content types and to existing sites. Notice that since we update the Page content type, also the Event content type will be updated since it inherits this content type
Notice that we only update the line with AdditionalDetails FieldRef entry, not the whole xml file

11. Expand the SiteMainResources feature node and open up SiteMainResources.Template.xml file by double clicking it

12. Update the template file as follows, so that there’s few upgrade actions to perform, when we upgrade from previous version to newer one

13. Update [PageID] and [CONTRACTID] stamps in the just copied xml element with the proper identifiers. You can locate the ID’s from the following locations. These refer to unique identifiers of the content types in following files:

[PageID] – SPIs – ContentTypes – Page – Elements.xml
[CONTRACTID] – SPIs – ContentTypes – Contract – Elements.xml

More on feature upgrade options and techniques

You can find more information on the feature upgrade options and techniques from Internet. In this case we used ApplyElementManifest first to introduce new field to site collection. After that we update the existing sites by using AddContentTypeField element. As a final element we use CustomUpgradeAction element to which we write the required code in following steps.

14. Since we will manipulate Publishign object model, we’ll need to add reference to Microsoft.SharePoint.Pulbishing.dll

15. Right click References in the Contoso.Intranet project and choose Add Reference…

16. Move to Browse tab and move to folder C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI

17. Select Microsoft.SharePoint.Publishing.dll and click OK

18. Open SiteMainResources.EventReceiver.cs to see the content of the feature receiver

19. Add following using statements to file

20. Add following override for FeatureUpgrading below FeatureDeactivating method

21. Open Contoso.Intranet Site Main Resources feature in designer and use properties window to set the version to 2.0.0.0

22. Right click Contoso.Intranet and choose Build

23. Right click Contoso.Intranet and choose Package

Note. DO NOT DEPLOY PACKAGE DIRECTLY FROM VISUAL STUDIO, since we will imitate production upgrades in following steps and if you use Visual Studio, your upgrade option is not available since Visual Studio will “try to help you” and it reinstalls features using activate/deactive commands, which doesn’t happen in actual production deployments.

24. Right click Contoso.Intranet and choose Open Folder in File Explorer

25. Move to bin – debug sub folder and verify that you have compiled successful Contoso.Intranet.wsp file, which is the actual solution package to be deployed

26. Copy current path to clip board, since we need to use that in PowerShell. If you are using defined guidance, path is following - C:\StudentWebTemplate\Labs\Contoso.Intranet\Contoso.Intranet\bin\Debug

27. Open SharePoint 2010 Management Shell from Start | All Programs | Microsoft SharePoint 2010 Products

28. Run following command in the PowerShell window

Notice that path depends on your solution structure location

Update-SPSolution -Identity contoso.intranet.wsp -LiteralPath "C:\Student\Labs\Contoso.Intranet\Contoso.Intranet\bin\Debug\Contoso.Intranet.wsp" –GACDeployment

Upgrade or Re-deploy

In this case we used Update-SPSolution cmdlet, but you could also do retract and deploy commands in PowerShell script. Difference is that when we use update command, none of the feature installed or uninstalled methods are executed, but if you have added features to your package, those don’t get installed either.

If you use retract – deploy method, feature installed and unistalled commands will be executed and possible new features are automatically installed. Key point to notice though that both options don’t activate or deactivate features in the sites, like Visual Studio does. This is critical difference between development and production environment deployments.

29. Run command “iisreset” in the PowerShell to ensure that updated xml files will be loaded to memory

30. Open Internet Explorer and browse to site http://intranet.contoso.com

31. Make sure that front page has not been checked out – you can publish it manually before moving forward

This is just due the code for the feature receiver, which doesn’t have exception handling if the page has been checked out.

32. Move to Site Settings page from the Site Actions

33. Click Site Collection Feature Upgrade link under Contoso Configuration

34. Notice that the Contoso.Intranet Site Main Resources feature is listed here as possibility to upgrade

35. Click Upgrade button

This will execute the FeatureUpgrading event definitions (code and xml based configurations)

36. Refresh page by pressing [F5] and verify that feature is not anymore listed to be upgrade

37. Move back to Site Settings page

38. Move to Site Content Types

39. Click Contoso.Intranet – Contract and ensure that Additional details fields has been added to content type

40. Move back to front page of the site and verify that web part was successfully added to the page

Upgrading features without custom application page

In this exercise we created custom application page to update feature. Depending on environment, PowerShell is much more convenient so that you have full control when upgrade is executed and nobody will upgrade features accidently just from the browser user interface.

If you find any issues on the lab, please add comments below, so that we are able to fix them as fast as possible. You can also suggest any enhancements for the lab, but due other on-going projects, I can’t promise to have time to include them. Thanks for your comments and feedback advance.

- Vesku

WebTemplate training materials - Lab 3 - Creation of WebTemplate for WCM site

2011-07-29T15:08:39Z

This post is lab 3 from series of training materials for WebTemplate creation and maintenance. Please check the following posts for details and other exercises. Notice that you can download full package with all required lab material from link available in introduction post. This package contains all supplementary materials and labs in word format.

WebTemplate training materials – Introduction to material
WebTemplate training materials – Lab 1 - Creation of features and basic structures
WebTemplate training materials – Lab 2 - Creation of custom navigation control and master pages
WebTemplate training materials – Lab 3 - Creation of WebTemplate for WCM site
WebTemplate training materials – Lab 4 - Upgrading existing sites with feature versioning

This particular post will concentrate on following functionalities.

Creating WebTemplate for Event site
Adding custom page layout which is used in WebTemplate to our solution
Creating required features and associations to onet.xml files for the WebTemplate

Lab 03 – WebTemplates and Page Layouts

The project files for this lab are in the ‘C:\Student\Labs\03_WCM’ folder

Lab Objective

Lab Overview: In this lab you will create actual WebTemplate and add custom page layout for it to be used automatically when site is created based on it.

Additional Resources

This lab includes the following additional resources:

Starter Files	C:\Student\Labs\03_WCM\StarterFiles	Files that can be used to help complete the labs.
Source Code	C:\Student\Labs\03_WCM\Solution	Completed lab source code for the status after this lab
Solution structure	C:\Student\Labs\Contoso.Intranet\	Solution structure started in previous exercise.

Getting Started

The default working folder for this lab is ‘C:\Student\Labs\03_WCM’.

Lab Setup Instructions

In the lab setup you will execute a PowerShell script that will create a new SharePoint site collection.

1. Start the Virtual Machine in Hyper-V.

2. Log on to the Virtual Machine as the local administrator with a user name of Contoso\Administrator and a password of pass@word1.

3. Open Windows Explorer and browse to the location C:\Student\Labs\Contoso.Intranet, in the folder double click Contoso.Intranet.sln to start the previously created solution structure.

This step assumes that you have already created lab 1 & 2 based on the lab guidance’s, so that we can continue building up the customization package.
Notice also that package contains full source code status after lab 2 in folder C:\StudentWebTemplate\Labs\02_UI\Solution\Contoso.Intranet - Lab 2 which you can copy as your starting point if you want to skip previous labs completely.

Exercise 1 – Creating Event Page Layout

In this exercise we’ll create page layout for the event content type, which was created earlier. This way content editors can easily create new events, which have nice editing experience for setting up metadata.

Task 1 – Adding page layout module

1. Expand the SPIs folder and Modules folders located in Contoso.Intranet project

2. Right click Modules and choose Add – New Item…

3. Choose Module and name it as EventPageLayout

4. Click Add

5. Select Sample.txt under the EventPageLayout module and delete it

6. Right click EventPageLayout and choose Add – Existing Item…

7. Browse to folder c:\Student\Labs\03_WCM\StarterFiles and choose ContosoEventPage.aspx

8. Click Add

9. Double click ContosoEventPage.aspx in the solution explorer and review its content

· This file defines the layout for individual event. Event fields have been associated to the page layout already

10. Double click Elements.xml file and update the content as in following code snipped

Properties for File element in module provisioning

We are defining properties for the file to be uploaded. These are not SPFile or SPPageLayout properties, rather column values for the file, which will be available in document library. In this case we define few additional properties (Page Layout and PublishingAssociatedContentType) so that page layout is properly available for pages created in the portal.

Notice also the Url attribute for the Module. This defines target of the file to be provisioned. Since we are provisioning page layout, we’ll need to set the target to _catalogs/masterpage.

11. Expand SPIs and ContentTypes folder in Content.Intranet project

12. Open Elements.xml file located under Event content type

13. Copy the ID of the content type to clip board – we’ll need to update this to page layout module

14. Move back to Elements.xml file located under the EventPageLayout module

15. Locate [ContentTypeId] string in the value of the PublishingAssociatedContentType property

16. Replace the tag with the just copied content type id of the event content type like in the following snipped - Since we’ll need to associate page layout to content type, we’ll need to ensure that the IDs will match. Notice that we’ll need to leave the hash and other chars in place.

Note. Don’t directly copy identifier as below, since value depends on your environment

17. Save changes

18. Expand Features node in the project structure and open up WebPublishingBinding feature in designer mode

19. Remove all other SPIs from this feature than the PublishingBinding, if there’s any other SPI’s

20. Open up SiteMainResources feature and ensure that all other SPIs except the PublishingBinding SPI is associated to it

21. Save changes

Task 2 – Testing page layout in the portal

1. Right click Contoso.Intranet project and choose Deploy

2. Ensure that deployment was successful from the output window

3. Open up Internet Explorer and move to address http://intranet.contoso.com · Depending on the master page currently defined on the portal, you might run into minor issues after deployment. If you’re unable to access the front page, perform following steps

Move to address http://intranet.contoso.com/_layouts/settings.aspx
Click Master Page under Look and Feel
Choose v4.master for both of the master page types
Click OK
Move back to Visual Studio and redeploy you’re customizations
Move back to http://intranet.contoso.com

4. Move to Site Settings from Site Actions menu

5. Click Master Pages and page layouts under the Galleries selection to ensure that Event page layout was successfully deployed – ContosoEventPage.aspx in the gallery

6. Move back to Site Settings

7. Click Page Layouts and site templates under the Look and Feel section

8. Under the New Page Default Settings, select Event Page layout to be the default page for new pages

9. Click OK

10. Select New Page from the Site Actions menu

11. Set name as MyExampleEvent - Note. If you’re currently using the custom Contoso master page, it has minor issues with the popup rendering due missing popup style definitions. Don’t mind those.

12. Click Create

13. Notice the Event related fields on the page layout, like Event Location and Event Date · Now we have successfully deployed also our page layout to site collection

Exercise 2 – Creating WebTemplate

In this exercise we’ll create new farm scoped web template, which will be used to create Event site for Contoso Intranet. We’ll use some previously created xml files to make the exercise easier. Web

Task 1 – Creating SPI for the Event WebTemplate

In this task we’ll create SPI for the web template and define the new site creation instruction, which we can use in following steps to create event sites.

1. Move to Visual Studio side

2. Expand SPIs folder and create new sub folder called WebTemplates

3. Right click WebTemplates folder and choose Add – New Item…

4. Choose Empty Element and name it was EventWebTemplate

5. Right click EventWebTemplate SPI and choose add existing Item

6. Browse to c:\Student\Labs\03_WCM\StarterFiles and select onet.xml file

7. Click Add

8. Activate onet.xml file in Solution Explorer and review the Property window. Notice that currently Deployment Type is NoDeployment – Update the property as ElementFile

9. Double click onet.xml file and review its content · Notice that there’s already definition to use the Contoso master as chrome master (ChromeMasterUrl property) in one of the features and there’s also default page layout definition also in place (DefaultPageLayout property).

Site definitions vs. WebTemplate element usage

If you’re familiar with Site Definitions from the 2007 version, this should seem familiar as well. Key difference is between site definitions and web template is the flexibility of the web templates in sense of customization updates and technically web templates don’t support definition of modules in the onet.xml. We can however provision modules for the site using associated features. This is done in the following task.

Check more concerning differences and usage models from my previous blog post.

10. Open Elements.xml file under the EventWebTemplate

11. Update the content as in the following snipped

Notice that since our WebTemplate is publishing template, we will use out of the box publishing template as the base template for future upgradability purposes (helps to movement to o15)

12. We’ll need to still modify the provisioning model of the WebTemplate. Right the Features node in the Contoso.Intranet project and choose Add Feature

13. Rename just created feature as FarmEventWebTemplate · In this case we deploy our Web Template to be available farm wide. You can also deploy WebTemplates using site collection scoped feature.

14. Open up feature designer (if not open, double click just created feature) and set initial properties as follows

Title – Contoso.Intranet Farm Event Web Template
Description – Deploys new event web template to be available in farm
Scope - Farm

15. Associate EventWebTemplate to feature

16. Open up WebPublishingBinding feature and ensure that EventWebTemplate SPI is not associated to it or to SiteMainResources feature

17. Save changes

Task 2 – Creating default feature and welcome page for the web template

In this task we’ll create default feature for the Event web template, which is responsible of deploying the default.aspx page for the site.

1. Right click Features node and choose Add Feature

2. Rename feature as WebEventWebTemplateDefault

3. Set properties of the feature as following

Title – Contoso.Intranet Web Event Web Template Default resources
Description – Default provisioner for the Event web template
Scope – Web

4. Expand the SPIs and Modules folders

5. Right click Modules and choose Add – New Item…

6. Select module SPI type and name it as EventWebTemplateDefaults

7. Delete Sample.txt under the EventWebTemplateDefaults module

8. Right click EventWebTemplateDefaults and choose Add – Existing Item…

9. Browse to c:\Student\Labs\03_WCM\StarterFiles and choose default.aspx and event1.aspx

10. Click Add

11. Open Elements.xml file located under the EventWebTemplateDefaults and update the xml as in the following snipped

12. Open WebEventWebTemplateDefault feature, set Is Hidden to True and copy the Feature Id from the properties window to clip board

13. Ensure that EventWebTemplateDefaults is listed in the Items in the Feature section and add also PulishingBinding SPI to the feature. IMPORTANT – Ensure that binding SPI is above the EventWebTemplateDefaults like in below picture. You might have to do some re-associations in the designer to achieve this.

14. Open onet.xml file located under the EventWebTemplate SPI

15. Locate following string from the onet.xml file: 

16. Place Feature reference just underneath the marker as in the following snipped. Note that feature ID in your case is different, since it’s randomly created during feature creation · This will ensure that feature is automatically activated when the web template is used for site creation

Task 3 – Add feature receiver to define initial settings for provisioned site

In this task we will stamp the site with custom property bag entry for traceability purposes using object model. You can then use this information in future to ensure that particular site has been created using specific WebTemplate.

Notice also that since we updated Web scoped feature to be hidden, you can use that as your versioning feature…. Those sites which has that feature enabled, are created using specific template and therefore you can version WebTemplate using this feature with feature upgrading definitions.

1. Right click WebEventWebTemplateDefault feature and choose Add feature receiver…

2. Remove all other methods, but replace FeatureActivated method as follows · Notice that we store the Name attribute value of the WebTemplate to property bag

3. Save changes

Task 4 – Deploy and test the structures

In this task we’ll create default feature for the Event web template, which is responsible of deploying the default.aspx page for the site.

1. Right click Contoso.Intranet project and choose properties

2. Move to SharePoint tab

3. Update Active Deployment Configuration as No Activation and uncheck also the Auto-retract after debugging to make future debugging experience little bit faster

4. Save all changes

5. Right click Contoso.Intranet and choose Deploy

6. Ensure that deployment was successful from the Output window

7. Move to internet explorer and to address http://intranet.contoso.com

8. Move to Site Settings page from the Site Actions menu

9. Move to Site Collection features under the Site Collection administration

10. Activate Contoso.Intranet Site Main Resources feature

11. Move back to Site Settings page

12. Click Page Layouts and site Templates under the Look and Feel

13. Add Events Site as one of the available site types

14. Click OK

15. Move back to front page of the site collection

16. Choose New Site from the Site Actions menu

17. Choose Events Site and define the properties as follows

Title - Events
Url - Events

18. Click Create - Creation of the site will take a while

19. Click Example Event from the left menu

20. Notice how we provisioned example template for event, with initial settings for Location and Title

21. Switch page to Edit mode

22. Notice how you can use specific controls to edit the event information

23. Save changes of the page

24. Choose New Page from Site Actions menu and ensure that default settings for the page layout were successfully applied so that our custom page layout is used by default

- Vesku

WebTemplate training materials - Lab 2 - Creation of custom navigation control and master pages

2011-07-29T15:05:24Z

This post is lab 2 from series of training materials for WebTemplate creation and maintenance. Please check the following posts for details and other exercises. Notice that you can download full package with all required lab material from link available in introduction post. This package contains all supplementary materials and labs in word format.

WebTemplate training materials – Introduction to material
WebTemplate training materials – Lab 1 - Creation of features and basic structures
WebTemplate training materials – Lab 2 - Creation of custom navigation control and master pages
WebTemplate training materials – Lab 3 - Creation of WebTemplate for WCM site
WebTemplate training materials – Lab 4 - Upgrading existing sites with feature versioning

This particular post will concentrate on following functionalities.

Creating custom navigation control
Adding custom master page for WebTemplate to Visual Studio solution
Adding custom navigation control to master page with required configurations
Adding required css and other UI related files to Visual Studio solution

Lab 02 – User interface customizations – Adding master page and custom navigation for WebTemplate

The project files for this lab are in the ‘C:\Student\Labs\02_UI’ folder

Lab Objective

Lab Overview: In this exercise we create custom main navigation control to be used in master page. We also include previously created style sheets and master pages to the solution structure, so that we can deploy all our customizations from one solution package.

Additional Resources

This lab includes the following additional resources:

Starter Files	C:\Student\Labs\02_UI\StarterFiles	Files that can be used to help complete the labs.
Source Code	C:\Student\Labs\02_UI\Solution	Completed lab source code in C#
Solution structure	C:\Student\Labs\Contoso.Intranet\	Solution structure started in previous exercise

Getting Started

The default working folder for this lab is ‘C:\Student\Labs\02_UI’.

Lab Setup Instructions

In the lab setup you will execute a PowerShell script that will create a new SharePoint site collection.

1. Start the Virtual Machine in Hyper-V.

2. Log on to the Virtual Machine as the local administrator with a user name of Contoso\Administrator and a password of pass@word1.

3. Open Windows Explorer and browse to the location C:\Student\Labs\Contoso.Intranet, in the folder double click Contoso.Intranet.sln to start the previously created solution structure.

This step assumes that you have already created lab 1 based on the lab 1 guidance, so that we can continue building up the customization package.
Notice also that package contains full source code status after lab 1 in folder C:\StudentWebTemplate\Labs\01_FeaturesAndVS2010\Solution\Contoso.Intranet - Lab 1 which you can copy as your starting point if you want to skip lab 1 completely.

Exercise 1 – Developing custom navigation control

In this exercise we’ll create custom navigation control, which will be used in the custom master page added in the following exercise.

Why custom control? – why not utilize out of the box things?

Whenever appropriate, it’s recommended to use out of the box navigation controls. In this case the user interface designer has however created CSS styling in such a way that we’ll need to create custom control to be used.

Task 1 – Creating custom navigation control

1. Right click Contoso.Intranet project and choose Add – New Folder

2. Rename folder as UI

3. Right click UI folder and choose Add – New Folder

4. Rename folder as WebControls

5. Right click WebControls folder and choose Add – New Item

6. Under the Web node, choose ASP.NET Server Control

7. Name control as TopNavigation.cs

8. Click Add

9. Right click Contoso.Intranet project and choose References…

10. From the .NET tab, add reference to System.Configuration

11. Move back to TopNavigation.cs

12. Add following using statements to code class

13. Remove the example code generated during class creation until the content looks like in the following code snipped:

14. Add following properties to the web control (inside of the class, after the class {-sign), so that we can manage the styling of the navigation more efficiently.

15. Add following below the properties to manage the data source attached to the control

16. Following step is to add the actual rendering logic, add following override for RenderContents method after the just added private property

This method will be responsible of rendering the navigation nodes as navigation

17. Following step is to add the actual rendering logic, add following RenderSubNavigation method after the just added private property

This method will render the child notes of the root node

18. As a final step for the navigation rendering, we’ll still need to have following methods included. These will render the individual links and spacer elements between the navigation nodes.

19. Save your changes

20. Right click the Contoso.Intranet project and choose Build to verify that code is fully available

Exercise 2 – Adding master page to solution

Master page has been previously created and we’ll add that one and supplementary files to our Visual Studio solution. We’ll also add the just created web control to master page, which will be responsible of the main navigation rendering.

Task 1 – Adding required resources to the solution

1. Right click SPIs folder in the project structure and choose New Folder

2. Name folder as Modules

3. Right click Modules folder and choose New Item…

4. Choose Module SharePoint element and name that as ContosoMasterPage

5. Right click ContosoMasterPage module and choose Add – Existing Item…

6. Browse to folder c:\Student\Labs\02_UI\StarterFiles and select Contoso.Intranet.Default.master

7. Delete the unnecessary Sample.txt under the ContosoMasterPage module

8. Modify the elements.xml file content as follows for the master page module. Notice the different settings we define to ensure that master page is deployed properly to master page gallery, so that master page is available for sites in the particular site collection.

9. Since Visual Studio automatically added this module to our previously created features, we’ll need to refactor and ensure the associations. Double click WebPublishingBinding feature under the Features node

10. Use Arrows to remove the ContosoMasterPage module from the particular feature if it’s present

11. Double click SiteMainResources and use arrows to associate module to this feature

Task 2 – Adding style sheets and other relevant files for master page

In this task we add images and style sheets, which are required for the master page.

1. Right click Contoso.Intranet project and choose Add – SharePoint “Layouts” Mapped Folder

2. Notice how Visual Studio Created automatically sub folder named as the project to avoid naming issues

3. Right click the Contoso.Intranet folder located under the Layouts and choose Add – New Folder

4. Rename folder as CSS

5. Right click just created CSS folder and choose Add – Existing Item…

6. Browse to folder c:\Student\Labs\02_UI\StarterFiles\CSS, select all CSS files using ctrl and click Add

a. These CSS files contains the style sheet definitions for the custom master page

7. Double click Contoso.Intranet.Default.master to open that on the working window

8. Locate place in head tags marked with following: 

9. Add following html references to master page to link up CSS style sheets to it

10. Save changes

Location for CSS files

Out of the box SharePoint structures deploy css files to Style Library, since files saved there can be modified using SharePoint Designer in the actual deployment. In this case objective is not to provide this customization option in production, so css files are deployed to _layouts folder. It’s always technical decision where to put these kind of files, depending on the business requirements and usage models.

Task 2 – Adding custom navigation control to master page

In this task we add the previously implemented custom navigation page to master page.

1. We’ll need to add that to our custom top navigation user control. Open the master page and place following registration element on top of the user control just below the Master statement.

2. We’ll still need to replace the fullyqualifiedname inside of the Assembly attribute. We can solve the fully qualified assembly name for example by using gacutil command line tool. Start Visual Studio Command Prompt from Start | All programs | Visual Studio 2010 | Visual Studio Tools

3. Run following command in command prompt – gacutil –l contoso.intranet

4. Copy the fully qualified assembly name to Assembly attribute. In your case the public key token is little bit different, but in the case of this exercise, values is as such:

5. Now that our assembly is registered on the master page, we can add our custom navigation to proper place

6. Locate place in master page marked with following: 

a. You can use find functionality to do this

7. Place following just below the commented marker - Notice that we link this control to ContosoSiteMap portal site map data source, which is located just below the control

8. Save changes · Since we are using custom control in our deployment, we’ll need to add required safe control entry also to web.config as part of the customizations. There are numerous different ways to achieve this automatically from solution package, but let’s now associate entry to module responsible of the master page deployment.

9. Activate ContosoMasterPage module and click […] from Safe Control Entries row in property window

10. Add entry as following to ensure that custom top navigation control added to solution package before will work properly

Namespace – Contoso.Intranet.UI.WebControls

11. Click OK and save changes

Task 3 – Testing master page in the site

In this task we ensure that master page is fully functional on the site and also test for the application pages.

1. Right click Contoso.Intranet and choose Deploy

2. Ensure from the Output window that deployment was successful

3. Move to Internet explorer and browse to address http://intranet.contoso.com

4. Choose Site Settings from the Site Actions menu

5. Click Master Pages and page layouts under the Galleries

6. Verify that Contoso.Intranet.Default.master is listed in the gallery

7. Move back to Site Settings page

8. Click Master Page under the Look and Feel

9. Choose Contoso.Intranet.Default.master from the Site Master Page selection

10. Click OK

11. Click the Contoso logo located in the top left corner to move to front page of the site

12. Move back to Site Settings page

13. Click Master Page under the Look and Feel

14. Choose Contoso.Intranet.default.master also to be used as system master page

15. Click OK

16. Notice how the application pages are also using Contoso branded master page

Example master page

This Contoso master page has minor rendering issues here and there, but it can be used for demonstrational purposes. Feel free to update or change it anyway you like, if you want to fix rendering issues.

- Vesku

WebTemplate training materials - Lab 1 - Creation of features and basic structures

2011-07-29T15:02:33Z

This post is lab 1 from series of training materials for WebTemplate creation and maintenance. Please check the following posts for details and other exercises. Notice that you can download full package with all required lab material from link available in introduction post. This package contains all supplementary materials and labs in word format.

WebTemplate training materials – Introduction to material
WebTemplate training materials – Lab 1 - Creation of features and basic structures
WebTemplate training materials – Lab 2 - Creation of custom navigation control and master pages
WebTemplate training materials – Lab 3 - Creation of WebTemplate for WCM site
WebTemplate training materials – Lab 4 - Upgrading existing sites with feature versioning

This particular post will concentrate on following functionalities.

Creating features and feature receivers – Introduction to VS2010 usage
Debugging feature receivers - Introduction to VS2010 usage
Starting creation of VS2010 project structures for more comprehensive customizations coming following labs
Creating site columns and content types for the upcoming WebTemplate created in following labs

Lab 01 – Getting started with Visual Studio 2010 and feature Framework - Creating required features for WebTemplate

The project files for this lab are in the ‘C:\Student\Labs\01_FeaturesAndVS2010

Lab Objective

Lab Overview: In this lab you will begin your work with Visual Studio 2010 and become familiar with the different options available and start creating the solution structure for upcoming WebTemplate deployment.

Additional Resources

This lab includes the following additional resources:

Starter Files	C:\Student\Labs\01_FeaturesAndVS2010\StarterFiles	Files that can be used to help complete the labs.
Source Code	C:\Student\Labs\01_FeaturesAndVS2010\Solution	Completed lab source code in C# for Lab01

Getting Started

The default working folder for this lab is ‘C:\Student\Labs\01_FeaturesAndVS2010.

Lab Setup Instructions

In the lab setup you will execute a PowerShell script that will create a new SharePoint site collection.

1. Start the Virtual Machine in Hyper-V.

2. Log on to the Virtual Machine as the local administrator with a user name of Contoso\Administrator and a password of pass@word1.

3. Open Windows Explorer and browse to the location C:\Student\Labs\01_FeaturesAndVS2010, in the folder double click SetupLab01.bat.

4. Verify the site created successfully message, and then press a key to close the prompt. The setup script launches a PowerShell script that creates a sample SharePoint site at the location http://intranet.contoso.com that you will use in the next exercises. If you use some alternative URL, you can update the script based on your own environment.

Exercise 1 – Creating Visual Studio Solution for project

In this exercise you will create initial structure for the upcoming solution using Visual Studio 2010.

Task 1 – Creating initial structure

1. Click Start | All Programs | Microsoft Visual Studio 2010. In the group of programs, right-click Microsoft Visual Studio 2010 and click Run as Administrator. This enables Visual Studio debugger to work correctly when attaching to the SharePoint worker process - In default SP2010 demo environment SharePoint is running using Farm Administrator account, so this would not be actually required, but this depends on the environment which you use for the lab exercises

2. On the Start page, in the Project section, click New Project.

3. In the Target Framework dropdown at the top of the page ensure .NET Framework 3.5 is selected.

4. In the Installed Templates section, in the Visual C# group, expand the SharePoint group, click 2010, and then click Empty SharePoint Project. - We use Empty SharePoint project, so that we don’t have any additional examples created to Visual Studio project structure. You can still add any kind of SharePoint items to this project, even though we initially started that as “empty” project.

5. In the Name textbox, type Contoso.Intranet.

6. In the Location textbox, type C:\Student\Labs\ and then click OK.

7. In the SharePoint Customization Wizard, in the What local site do you want to use for debugging? textbox, type http://intranet.contoso.com/ · Notice that url is dependent on your environment.

8. Select the Deploy as a farm solution option.

9. Click Finish.

Task 2 – Reviewing the project nodes

In this task you will examine the four nodes created in a SharePoint 2010 project. The nodes Properties and References are standard on Visual Studio projects, whereas Features and Package are unique to projects created with Visual Studio 2010 SharePoint Tools.

1. Right-click the Features node and choose Add Feature. A feature with the name Feature1 is added. Right-click on this node and click Rename. Rename this feature to SiteMainResources

2. In Solution Explorer, right-click SiteMainResources and click View Designer.

3. In the Title textbox, type Contoso.Intranet Site Main Resources.

Good practice – prefixes for features

We use Site prefix for the feature node in the solution to indicate its scope easily without opening up the feature. Name of the feature node also defines the folder name of the feature in the 14 root. We use also Site in the title, so that we can see the scope of the feature easily from the packaging explorer, which we use later in this exercise

4. In the Description textbox, type Main resources for Contoso.Intranet.

5. Click the Scope dropdown list and then click Site. · Note: Site columns and content type deployment requires a feature which activates at site collection scope in order to properly deploy Web Part description files.

6. Save changes.

Task 3 – Adding images to a SharePoint 2010 Project

Visual Studio tries to ensure best practice by adding images to a project specific sub-folder in the images containing folder. This avoids naming conflicts with images that Microsoft deploys in the Images location.

1. In Solution Explorer, right click Contoso.Intranet, click Add and then click SharePoint “Images” Mapped Folder.

2. In Solution Explorer, in the Images node, right-click Contoso.Intranet folder and click Add Existing Item….

3. Browse to the folder C:\Student\Labs\01_FeaturesAndVS2010\StarterFiles and, holding the [CTRL] key, select the files named FeatureIcon.gif, SiteIcon.gif and WebPartIcon.gif.

4. Click Add.

5. In Solution Explorer, expand Features, double click SiteMainResources feature - This opens up the properties sheet for the particular feature.

6. In the Properties sheet for the feature, in the Image URL property, type Contoso.Intranet\FeatureIcon.gif · This is good practice to differentiate your features from the out of the box features in UI

7. Click Save.

Exercise 2 – Adding a Feature Event Receiver

In this exercise you will add a feature receiver. This will automatically execute during feature activation and feature deactivation. In this exercise you will:

Obtain the SPSite reference which points to the site collection in which the feature is being activated.
Obtain a SPWeb reference which points to the top-level site.
Query the top-level site's Title property and store the value as a name/value pair inside the SPWeb.Properties collection.
Modify the site's Title property with a creative text value of "Contoso Intranet"
Modify the site's SiteLogoUrl property to point to SiteIcon.gif inside the Images folder.

Notice that this is just preliminary exercise before we start actually creating structures for required WebTemplate structures.

Task 1 – Creating event receiver

In this task you will edit the project code to make use of an event receiver.

1. In Solution Explorer, expand Features, right click Main and click Add Event Receiver.

2. SiteMainResources.EventReceiver.cs opens in the editing window. Note the code stubs and the unique Guid for the feature. Guid is used by Visual Studio to associate proper feature receiver to correct feature.xml file.

3. Uncomment the method named FeatureActivated and FeatureDeactivating. Then remove all the extraneous comments. Your code should look as follows (Note. Don’t copy this code, uncomment the existing so that Guid attribute is correct):

4. Add following code between the braces {} in the FeatureActivated method · Notice that we use prefix Contoso.Intranet when we store our own custom properties to property bags to avoid overlapping with any out of the box properties. This is really good practice to follow up in your real life projects as well.

5. Add following code between the braces {} in the FeatureDeactivating method - In this code we reset the site back to the status it was before the code was executed. This is good practice to follow up in your own customizations as well.

6. On the File menu, click Save all.

7. In Solution Explorer, right-click on the Contoso.Intranet and click Build.

7. At the bottom of the Visual Studio Window, click Output to see the results of the build. Verify the code builds correctly. Leave the project open, you will deploy and test the code in the next Exercise · Note. If Output is not visible, you can get it opened by selecting Output from View menu

Exercise 3 – Deploying and Debugging SharePoint Projects

In this exercise you will deploy your solution and then activate it on the SharePoint site collection. Finally you will debug the solution.

Task 1 – Review deployment options and Output window results

1. In the Solution Explorer window, right-click Contoso.Intranet and click Properties.

2. Click the SharePoint tab.

3. In the Active Deployment Configuration dropdown list, click No Activation.

4. In the Edit Configurations list box, click No Activation and then click View - Notice that you can control deployment and retraction settings from here. Review the different options available.

5. Click OK to close the dialog.

6. Save changes

7. Ensure the output window is visible at the bottom of the screen, then in Solution Explorer window, right click Contoso.Intranet and choose Deploy · Review the steps that are specified in the Output window.

8. Leave the Visual Studio project open, you will return to it in a later task.

Task 2 – Reviewing the feature in the SharePoint site collection

The solution package for the Contoso.Intranet project has been deployed on the local SharePoint. In this task you will test the work.

1. Open Internet Explorer and browse to http://intranet.contoso.com

2. Click the Site Actions menu, and then click Site Settings.

3. In the Site Collection Administration section, click Site Collection Features. In the list of Features, review the Contoso.Intranet Site Main resources feature and its custom icon.

4. To the right of the Contoso.Intranet Site Main Resources feature, click Activate.

5. In the title bar to the top left of the features, click Contoso Intranet · Review the new site Icon – since we are using publishing features, title of the site is not visible from here.

6. Click the Site Actions menu, and then click Site Settings · Notice that the site title set in the feature receiver is visible here.

7. In the Site Collection Administration section, click Site Collection Features.

8. To the right of the Contoso.Intranet Site Main Resources feature, click Deactivate.

9. On the warning page click Deactivate this feature.

10. Refresh page by clicking [F5] · The site icon and title have returned to the default.

Task 3 – Debugging the project

In this task you will use Visual Studio 2010 to debug your project. You will create breakpoints and then step through the code.

1. Return to Visual Studio 2010.

2. In Solution Explorer, expand the Features branch.

3. Right-click SiteMainResources.EventReceiver.cs and click View Code.

4. Locate the cursor in the line SPWeb site = siteCol.RootWeb; on the toolbar click Debug, and then click Toggle Breakpoint (or F9 as short cut).

5. On the Visual Studio menu, click Debug and then click Start Debugging. The solution builds and a new instance of Internet Explorer is launched.

6. In the Debugging Not Enabled message box, click OK.· Note. This happens only for the first time particular web application is used for debugging. · Note. Starting the debugging process could take a while, so wait patiently

7. Click the Site Actions menu, and then click Site Settings.

8. In the Site Collection Administration section, click Site Collection Features.

9. To the right of the Contoso.Intranet Site Main Resources feature, click Activate.· Visual Studio Editor opens and the code stops at the breakpoint.

10. Press [F11] to step through the code.

11. Return to Visual Studio on the menu click Debug, and then click Stop Debugging.

12. Locate the cursor in the breakpoint line and click [F9] to Toggle the breakpoint off.

Exercise 4: Creating and deploying content types for the solution

In the remaining exercises you will add few new SharePoint Items to the project using empty and content type templates. We are starting to building up the data structure model for our upcoming Contoso.Intranet solution, which will be based on WebTemplate techniques.

Task 1 – Creating site columns

In this task you will add a Web Part to the project. You will edit the XML files to specify a different category for the part.

1. In the Solution Explorer window, right click Contoso.Intranet, click Add, and then click New Folder.

2. Rename folder as SPIs - SPIs is just shortening from “SharePoint project item”. We use this folder to group our SarePoint specific structures to sub folders so that solution structure remains understandable and also others working in project can easily understand what’s included in it.

3. Add also new sub folder to this folder, named as SiteColumns

4. Right click SiteColumns, click Add, and then click New Item.

5. In the Installed Templates section, in the Visual C# group, expand the SharePoint group, click 2010 and then click Empty Element.

Empty template

Since there’s no out of the box template for site columns, we’ll be using Empty Element for defining our required fields. You can use this approach for any SharePoint projects items, which don’t have dedicated template available.

6. In the Name textbox, type InitialFields.

7. Click Add. The InitialFields node is added to Solution explorer with elements.xml file.

8. Double click the Elements.xml file located under the Initial fields

9. Open up fields.txt located in the c:\student\labs\01_featuresAndVS2010\StarterFiles and copy the content between the Elements elements in the Elements.xml file as follows:

10. Review the xml content – we create the required fields for the upcoming event functionality which has specific metadata used in page layouts. In this case we add three different fields related to upcoming event functionality.

Task 2 – Creating publishing content types

1. Right click the SPIs folder and create new ContentTypes sub folder

2. Right click the ContentTypes folder and choose Add – New Item

3. In the Installed Templates section, in the Visual C# group, expand the SharePoint group, click 2010 and then choose Content Type

4. Name content type as Page· This will be our Contoso specific root page for the publishing sites.

5. Click Add

6. Choose out of the box Welcome Page as the base content type for this content type

7. Update the Group attribute of the content type as Contoso Content Types

8. We don’t need to associate any additional fields to this content type in this stage, so the definition should look as follows. Notice how the name is project specific to follow naming guidance

Content type inheritance

This content type is created as the root content type for the custom publishing content types in this project. This way we can easily extend any custom content types, by manipulating this definition in future phases of the Intranet

9. Right click the ContentTypes folder and choose Add – New Item

10. Choose Content Type and name the content type as Event

11. Click Add

12. Choose Contoso.Intranet - Page as the base content type

13. Update the Group attribute as Contoso Content Types

14. Open up fieldrefs.txt located in the c:\student\labs\01_featuresAndVS2010\StarterFiles and copy the content between the FieldRefs elements in the Elements.xml file as follows: · Important – Don’t copy the snipped directly from below, since the content type GUID depends on the environment. Replace only the field references.

Task 3 – Creating document content types

1. Right click the ContentTypes folder and choose Add – New Item

2. Name to be added content type as Contract

3. Click Add

4. Choose content type to be based on out of the box Document content type

5. Update the Group attribute as Contoso Content Types

6. Open up statusref.txt located in the c:\student\labs\01_featuresAndVS2010\StarterFiles and copy the content between the FieldRefs elements in the Elements.xml file as follows: · Notice that we are using out of the box site column, so we only need to reference it here

This content type is only for feature upgrade demonstrations, so we don’t include any actual custom word template for it in this exercise

Task 4 – Creating content association for publishing pages

In this following task we create necessary content type binding element, which will be responsible of adding publishing content types to be available in the pages library. Unless we do this, content editors cannot create new pages with the soon to be created page layout.

1. Right click Features node in the Solution Explorer and choose Add Feature

2. Rename the newly added feature as WebPublishingBinding · This is web scoped feature, which is used for binding content type to site. In this series we actually create this just for verification purposes, so we don’t actually use this web scoped feature at all when WebTemplate has been fully created.

3. Update title and description as follows

Title – Contoso.Intranet Web Publishing Binding
Description – Content type binding feature

4. Ensure that the Scope is set as Web

5. Right click the SPIs folder and choose Add – New Folder

6. Name folder as ContentTypeBindings

7. Right click the ContenTypeBindings folder and choose Add – New Item

8. Choose Empty Element and name that as PublishingBinding

9. Open up Bindings.txt located in the c:\student\labs\01_featuresAndVS2010\StarterFiles and update the content as follows: · Notice that you’ll need to update [ContentTypeId] places with the content type ids in your environment. These are the IDs of the content types, which we just created in previous SPIs, which we added to the solution.

10. Your solution should look somewhat as in following picture

Task 5 – Verifying outcome

In this task we verify the configure setup by reviewing the packaged content and how the structures are generated to site collection after deployment

1. Choose Package Explorer from the View - Other Windows menu

2. Ensure that the elements are in proper features – as all site columns and content types in site collection scoped feature and binding in web scoped feature - Notice that the Feature Titles are visible here, so it’s good practice to name them properly - Notice also that you’ll need to have fields before content types listed in feature, since other of the project items in the features really matters.

3. Right click the Contoso.Intranet project and choose Properties

4. Move to SharePoint tab and modify activation to be Default

5. Save all changes – for example by selecting Save All from File menu

6. Right click Contoso.Intranet project and choose Deploy

7. Open up Internet Explorer and move to url http://intranet.contoso.com

8. Choose Site Settings from the Site Actions

9. Click Site Content Types under the Galleries

10. Ensure that you can see the just created three content types in the list · Notice also that site icon has been updated automatically by site collection scoped feature activation

- Vesku

WebTemplate training materials–Introduction to reusable labs

2011-07-29T14:59:08Z

During past few years I’ve been doing quite a lot of training materials which have been then published globally in MSDN or in other places. Every now and then some of the material don’t get officially released due miscellaneous reasons, so I’m quite often left with numerous demos and HOLs which were cut from some package.

This post is introduction post for that kind of material, which is now released in this blog and you can also download the full package from my personal sky drive (word format with supplementary files). This material has created by me for one hands on training where objective was to continue building existing solution from scratch to finish – as in step by step, rather than doing individual bits and pieces as the exercises. These kind of exercises have received excellent feedback, since they keep the context for the technologies covered in individual labs.

Now released package will contain following exercises or topics, which will be released also as blog posts.

Creation VS2010 solution structure for WebTemplate and feature deployment following up naming guidance's and folder structures
Creating features and feature receivers
Debugging feature receivers
Creating site columns and content types
Developing custom navigation control for controlled html
Deploying custom master page using feature with custom navigation control
Adding and deploying custom page layout to solution
Creation of WebTemplate with publishing features enabled (WCM site) utilizing above customizations
- Business case - Creation of Events site to show information concerning upcoming events in corporation
Creating custom Upgrade application page to site settings for feature upgrade management
- Check Chris O'Brien's solution for more comprehensive functionality for feature upgrade management from central administration application
Upgrade existing sites created using old version of the web template with feature upgrading techniques
- Check more details on the model in my previous blog post

Here’s the links to released blog posts

WebTemplate training materials–reusable labs – Lab 1
- Creation of features and basic structures for our solution
WebTemplate training materials–reusable labs – Lab 2
- Creation of custom navigation control and master pages
WebTemplate training materials–reusable labs – Lab 3
- Creation of WebTemplate for WCM site with custom page layout
WebTemplate training materials–reusable labs – Lab 4
- Upgrading existing sites with feature versioning

Just a teaser on the web template created publishing site with custom navigation and master page…

You can also download zip package, which includes Word document versions of the hands on labs, all required prerequisites for the labs and example implementations of the labs. Downloadable package is available from here. Exercises assumes that you have extracted this package to c:\Student folder of your development server. If you want to copy-paste xml and code used in the exercises, Word format is much more suitable – it’s up to you…

Labs can be performed almost in any environment and they are using same domain information as in the publicly available Hyper-V image with Contoso corporation demo structures. Simply adjust the url and domain information to match your own environment, if you have some alternative SharePoint environment for your consumption.

Feel free to utilize now published material anyway you like – you can freely utilized parts of it or update it as you like. Please note that I don’t take personally no responsibility what so ever with the now released package, so they are meant for learning exercises, not directly to be used in any actual SharePoint deployment.

If you find any issues on the labs, please send comments, so that we are able to fix them as fast as possible. You can also suggest any enhancements for the lab, but due other on-going projects, I can’t promise to have time to include them with the exercises. Thanks for your comments and feedback advance.

- Vesku

Site definitions vs. Web templates

2011-07-22T14:45:18Z

I keep getting almost daily emails concerning WebTemplate element support and when it would be proper technical approach for the site provisioning with SharePoint 2010. There’s no doubt that many times there’s requirements to be able to provision sites as easily as possible from content editor perspective, so let’s still elaborate or evaluate different options and common misunderstandings with these options.

Detailed explanation of different available options can be found from my previous blog post (also has step by step guidance on custom WebTemplate usage). Mirjam also has done good work on explaining WebTemplate in her blog post titled as same as this one. Notice that when I’m writing about web templates, I refer to WebTemplate element usage with onet.xml, not what get’s created when you save site as a template from browser (site template wsp package), even though site templates uses WebTemplate element in them.

Here’s quick list of advantages and disadvantages on both approaches. Let’s also add some cloud perspective on the topics, since it seems to get cloudier and cloudier all the time, especially now with the Office365 being released few months back.

Notice that I didn’t include feature stapling or features to the game, since in this post we’ll concentrate on having new options available in the Create Site functionality, rather than just changing how the existing templates will work using feature stapling or manual feature activation. Following chapters will list random pointers for both sides (advantages and disadvantages) which you should be considering when you create your technical plan for customizations.

Site definition

There’s no supported way to upgrade or modify already deployed site definition
- It might work, but it’s not supported
- There’s options to mitigate this, but there’s wider impact on architecture planning and technical solution
Site definitions are always deployed farm wide and cannot be targeted to more granular scope
There’s own template in VS2010 for site definition
Feature staplers can be targeted to site definitions
Variations will only work with site definitions
- Note. This is not translation or multilingual solution, it’s for structural copy. Following sites as an example are not using variations – www.kone.com in English (US), Chinese and in Russia
Not supported by cloud services, like Office365 (Standard or Dedicated)
Upgrades to following SharePoint major version (o15) will require additional costs
- All sites created using custom site definitions are stamped with custom identifier and won’t be upgraded automatically
Hierarchies can be easily created using separate xml formats
- Requires usage of portal site templates, which is one example of site provisioning provider implementation
Only supported as farm solution deployable functionality

Web Templates

Can be easily updatable just by modifying onet.xml and deploying new version of that available
- Note. Update does not have any impact on existing sites, since there’s no runtime reference to them
Can be targeted to Farm or Site collection level – provide more granularity for exposing site options
Feature staplers cannot be targeted to web template
- Note. Since you can modify onet.xml directly and deploy new version of that anytime, there’s no use for feature stapling with WebTemplate element
Variations won’t work with WebTemplate element deployed onet.xml files
- There’s already few custom solutions available, which makes variations also to work with sites created using WebTemplate elements. Logic is not that difficult, but requires customizations
Supported by cloud services, like Office365 (Standard or Dedicated)
Upgrades to following SharePoint version (o15) won’t require extra work – completely same as somebody would have created site using out of the box site definition and then activated extra custom features from site settings page
- Actual features have be obviously upgraded correctly
Supports publishing features, like site definitions – so can be also used for Internet facing sites
- Good example of Internet facing site created using WebTemplate elements in www.upm.com which also has numerous different languages (France, German, Finnish)
Hierarchies can be easily created using feature receivers and code
- Provides actually more flexibility than portal site template option
Creating custom web template is easy as creating custom site definition
- Note. Don’t start by importing existing site template (wsp package) as suggested in the MSDN. It’s much more easier to convert any existing site definition to web template simply by copying onet.xml and creating other required elements manually. Check my previous blog post for details.
There’s no designers in VS2010 for WebTemplate
- This should be fixed by VS.next to promote multiple platform options – as in not to force to be only in on-prem like with site definitions – “We are all in…”
Can be deployed from farm solution or from sandbox solution
- Notice that has to be obviously in Site Collection scoped feature, if deployed as Sandbox solution

I upgraded from 2007 and have site definitions – now what?

In 2007 we didn’t have any other options than using site definitions with certain business requirements, so it’s understandable that there’s numerous sites which are build technically using custom site definitions. These deployments won’t be cloud compliant unless dependency to these site definitions is removed. This means that these kind of deployments cannot be migrated to Office365 (Standard or Dedicated) without complete refactoring of code and content as pre-requisite.

These kind of refactoring projects are not simple and could be surprisingly expensive. If you are planning to migrate away from custom site definitions, you might want to consider to take a approach where you rebuild customizations using WebTemplate element and then migrate just the content from the existing sites to newly developed customizations. You might want to consider this as one of your options when you define required changes for the customizations anyway due the version upgrade from 2007 to 2010.

Summary

As a summary, you should be using WebTemplate element whenever possible to provide site provisioning options to your deployment.

As a Microsoft consultant, I also personally would prefer people to use more cost efficient options in long term when they design their customizations to avoid any hidden cost impact or unnecessary cleaning in later stages of the deployment life cycle. By using WebTemplate element over site definition, we still provide complete flexibility for the customers to host their SharePoint wherever they want (cloud or on-prem) and don’t cause any “stupid” technical limitations for their possible future cloud transition to any cloud platform (like Office365). Even though your deployment would have been currently planned to be an on-premises deployment, you shouldn’t lock it’s future by using site definitions and cause also additional costs as part of the upgrade to following SharePoint major version (o15).

Hopefully you were not forced to do any SP2003 to SP2007 upgrades where custom site definitions where used, but that’s exactly the route where using site definitions also in future will drive deployments. These migration issues should be major consideration point for any SharePoint deployment from overall costs perspective. By selecting WebTemplate approach, your deployment will be as easily updated to following SharePoint major version as it would be using simple stapled features. This has major cost impact on the overall lifecycle costs of the deployment.

Notice also that since WebTemplate element usage is also based on same onet.xml structures like site definitions, you can easily learn how to use them, so that your customization architecture is following up guidance's to avoid any unintentional costs for the deployment during maintenance phase of the sites.

So – forget site definitions, start using WebTemplate elements in your deployments, this will be beneficial for your customers, you and any SharePoint deployment in short and long term.

If you disagree any of the pointers listed above, don’t hesitate to contact or write comments on this blog post. We would like to also understand what are the concerns and possible issues you might have run into. Thanks for the comments and pointers advance.

SharePoint 2010 and web templates

2010-10-14T17:34:56Z

One of the really exciting new options on the Feature Framework level of the SharePoint 2010 is the WebTemplate element. In this blog entry we’ll cover the primary site provisioning methods and we’ll concentrate especially to web template option to share the key techniques.

Introduction
Different site provisioning methods in SharePoint 2010
Web template option in detail
Additional design guidelines for web templates
Step by step creation of new publishing web template
Web Template FAQ
Summary
References

Introduction

As you might know, there are multiple different techniques for provisioning new sites in SharePoint. SharePoint deployments always consist from at least one site, which provides functionalities for the end users. There’s multiple ways to create these sites and to customize them based on customer requirements. In this blog post we concentrate models, which support strict versioning model. Meaning that the sites are not built directly to production environment using SharePoint Designer or browser rather deployed using solution packages.

Before we get started, let’s first concentrate on getting the terms right. There’s multiple different terms used when we reference definitions, which are used for creating new sites. Here’s the clarification on the most used one’s and how they should be used.

Site Template
- Site template refers to WSP package, which was created by clicking the Save Site As Template link in the Site Settings page. In SharePoint 2007 sites were saved to specific STP format, but in SharePoint 2010 templates are using the standard SharePoint solution package model.
Web Template
- Web template refers to new feature element available in SharePoint 2010, which provides us flexible way to define definition (onet.xml file), which will be used only on provisioning time, when the site is created. There are no references to the definition on runtime, which provide easy maintainability for the definition.
Site Definition
- Site definition refers to classic WebTemp*.xml and onet.xml combination, which are located in the file system of server. WebTemp*.xml file is used to introduce the template for SharePoint and onet.xml file contains the actual instruction or definitions concerning which features to activate when site is created.
Portal site template
- Portal site templates are hierarchy files, which are available when you use SharePoint server. Portal site templates have their own xml schema, which is used to define which kind of site definitions are provisioned and in which order. Good example of portal site template is out of the box publishing portal definitions, which provisioned example www site, with single sub site.

Why is the provisioning model such an important thing? – since overall usage models in SharePoint, especially for larger companies, are not just based on individual web parts, which are used to bring additional value over the out of the box site structures. In larger project, the productivity of the individual end users and the editors plays role for designing correct model, since we want to have as good and consistent user experience provided through out the farm.

Let’s have a real life example of one global intranet, which had 50 part time content editors and more than 700 sites in site hierarchy for each of the country sites. There’s 10 different site types, which should provide the same functionality where ever they are located. Since there’s quite a lot of content to be created and managed, it’s better to create specific templates compared to use feature stapling and browser customizations. You can only image the time spend modifying each site using browser and even though there would be documented instructions, most likely most of the sites would look little bit different than other. By providing 10 configured web templates, which will have all templates and web parts as defined by corporate communication, intranet will have consistent user experience and content editors can easily extend the sites as required.

Key point on the site provisioning is to automate something which would be done manually by site authors. Business case can be calculated quite easily from the amount time required for each site to be configured based on the company guidance. There doesn’t have to be that many sites created, before the investment for customization is worthwhile.

I’ve been still seeing demos and real production environment where the end users or content authors are forced for example to active features manually in certain order to configure the site as planned. This should not be the case, since it also increase risks of breaking up the sites by for example activating accidently wrong features.

Other consideration is obviously the implications due the customizations. Certain options available can cause implications on maintenance and upgrade processes, which will impact on the overall costs included in the deployment. Luckily in SharePoint 2010, we now have the new Web Template option, which will help to address these issues.

So key advantage of automating the site provisioning to save time and ensure consistent end users experience throughout the particular deployment. This is not only important for WCM sites, but also for other site types to provide consistency.

Different site provisioning methods in SharePoint 2010

There is four or five different main models for site provisioning in SharePoint 2010, depending what’s considered as individual models.

Feature stapling
Site templates
Web Templates
Site definitions
Provisioning provides
Custom code (mainly for automated processes)

We’ll cover each of the options in high level to consider the different advantages and disadvantages in each of them, except the full custom code option, which obviously can be anything. These options will concentrate on different ways to control what’s provisioned when end users uses the out of the box Create functionality.

Feature stapling

Primary purpose of the feature stapling is to extend and customize existing site definitions. Usually these are used to provide some custom functionalities for the out of the box site definitions, but technique is definitely available also for the custom site definitions.

Since it’s not supported to change the onet.xml file of site definitions after it has been used in environment, feature stapling is quite commonly used also to provide versioning for the already deployed custom site definitions. You can modify the stapling definitions to different site definitions also afterwards. It’s important to remember that stapled features are only activated on provisioning time, so if there’s any existing sites already provisioned, those won’t be affected automatically just by deploying new stapling definitions.

Biggest downside with the feature stapling is that we can only extend the existing site definitions, we can’t provide new. This can be an issue for example when you’d like to have WCM templates created for multiple different site purposes. Also the fact that stapled features are activated before the module element or list elements in onet.xml file has been provisioned, can cause issues unless you use some workarounds. Notice also that feature stapling is only supported when site definitions are used, it doesn’t work if you are provisioning sites using site templates or web templates, even though these both options refers to root site definition.

More information

More information concerning feature stapling in SharePoint 2010 can be found from following locations:

MSDN – Feature/Site Template Association – quite misleading title, but it works only against site definitions

Site templates

As you might know SharePoint 2010 has changed the functionality used for saving existing sites as template. In 2007 version when site was saved as a template, specific STP file was created, which could not be modified in anyway. In 2010, when we save site as template, SharePoint generates full fledge solution package (WSP file), which can then be moved between any environment containing all site level objects, like libraries and optionally also content.

There are two key improvements in feature framework scheme, which have made this possible. These are WebTemplate element and CustomSchema attribute for ListInstance elements. These two options will make it possible to provision sites using alternative xml definitions, but then refer back to out of the box templates. Key point is that we use alternative definitions during provisioning, but all object references will be associated to out of the box types.

One of the biggest downsides with the site templates is the fact that they are not supported when publishing features are enabled. This is also the reason why we hide the link from the site settings page to avoid anyone to use this functionality. Obviously if you know the aspx page name, you can access the page and save the site as a template also when publishing features are enabled. This is however not supported. What does that mean? – just because you can… doesn’t mean you shouldn’t. Publishing sites have complex references and dependencies, which have to be carefully defined even for site definitions. This is not supported (and link is hidden) so that inexperienced users wouldn’t break intentionally their deployments.

One of the consideration with the site templates is also the fact that unless you import them to Visual Studio and modify its settings, they are only available on site collection level (site collection scoped feature), which means that to be able to have the template available from multiple locations, we’ll have to either deploy the site template as sandbox solution to multiple site collections or deploy it as full trust solution and then activate the particular feature in site collections to have the template available.

More information

More information concerning Site Templates can be found from following locations:

Office – Save a SharePoint site as a template
MSDN – Application life cycle for SharePoint 2010 – there’s some content concerning site templates included here as well

Web Templates

We’ll concentrate more detailed on the Web templates in later chapters, but basically with the web templates in this case, we refer to manually created WebTemplate elements in the Visual Studio. We need to create two files for each of the web templates. Other one is empty element (is VS2010 is used) for defining the actual WebTemplate element and other one is completely similar onet.xml file as for site definitions, with few exceptions, which we’ll cover little bit later.

When we have our web template created, we’ll associate the element file to feature, which will be responsible of deploying the web template. WebTemplate element is supported in two scopes, which are Farm and Site. This means that we can deploy the web templates to be available either throughout the farm or based on site collection scoped feature activation. It’s important to notice that dispute the fact that we’d be using site collection scoped feature for deployment, we can still deploy the web template using farm scoped feature. This would for example give us possibility to filter the options available from the Create site functionality, based on feature activation status.

One big advantage of the web templates is the fact that since they are feature based and there won’t be any files stored in file system, those are completely supported usually by the cloud services, like MS Online (BPOS). Support obviously varies based on the cloud service types, like in MS Online case, if the service is dedicated or standard. These usually mean for example differences on the support for full trusted solutions or only sandbox solutions.

One really important advantage with the web templates compared to the site templates is the fact that we can utilize the publishing features in web templates. This provides us possibility to create new site provisioning options to be available from the Create site functionality, even though we would be creating new publishing feature based sites..

We’ll walk through exact details and web template creation is upcoming chapters.

More information

See end of the article for references and links concerning web templates and manual creation of them.

Site definitions

Site definitions are the classic xml files, which are for example used to provision out of the box sites. Many of the developers learned to create these in 2007 version, since they are very powerful and there were almost no other options available for introducing new options for the Create site functionality. As mentioned earlier site definition consists basically from two different files: WebTemp*.xml and onet.xml files.WebTemp*.xml defines how the site definition is visible for the end users and the onet.xml file contains the definitions for the actual site provisioning.

We can only deploy site definitions using farm solutions, since files will be located in the file system. They are also by default available throughout the farm in every application, unless we limit the visibility either using AvailableWebTemplates attribute for publishing sites or more generally available VisibilityFeatureDepency attribute in the WebTemp*.xml file. Since we won’t be concentrating on site definitions in this blog article, I won’t be covering these options more detailed.

Key change in the site definitions for the 2010 version is that if you have site collection scoped feature associated to site definitions under the SiteFeatures elements, those features are not activated, if you create sub sites. In 2007, also these site collection features where activated also for sub sites. This could be an issue when for example you want to add new Events site under corporate intranet and you’d like also for example content types to be created, when site is provisioned. There are workarounds for this, which are declared later in the web template creation chapters (same workaround applies for site definitions).

Whenever we create site based on any site definitions SharePoint stores the site definition identifier information to SPWeb.WebTemplate, SPWeb.Configuration and SPWeb.WebTemplateId properties. These are critical properties in the SharePoint platform, which have to be set for each of the sites. Let’s come back to this in following chapters with detailed web template information.

Biggest challenge with the site definition is that we are not allowed to change the onet.xml file after it has been used to provision any sites in the environment. This is just not supported. There are certain scenarios, which don’t impact the existing sites and it might seem that update didn’t cause any issues, but just because it didn’t hurt the first time, should you do it again? – no. This is one of the classical rules of SharePoint development, like the fact that don’t touch the databases directly.

Already in 2007 version there was numerous approaches to go around the fact that onet.xml file should not be updated. Most classic one, is the so called “minimal site definition approach”, where we all possible customizations to features, which don't’ have to be activated in certain order. Let’s not spend too much time on this, but generally out of the box site definitions are actually quite awful examples for custom site definitions (quick summary).

Due these upgradability issues and SLA commitments with the customers, site definitions are NOT supported usually by the cloud services, like in MS Online. It would be simply foolish to impact on the service quality by allowing site definitions to be used, especially since we have at least as good options available in SharePoint 2010, which don’t compromise the service in short or long term.

More information

More information concerning the site definitions can be found from following locations:

MSDN – Site definitions and configurations

AC - Using Minimal publishing site definition in field

Provisioning providers

Portal provisioning providers are technique where we completely replace the onet.xml file using code, except that we usually still use some out of the box site definition as the starting point. This means that we only use WebTemp*.xml file and assign our custom provisioning class to be used, when particular template is selected. As long as we have implemented our custom provisioning provider by inhering the out of the box SPWebProvisioningProvider class (Microsoft.SharePoint.SPWebProvisioningProvider) and the associations in WebTemp*.xml are correct, we would have full control on the actions to be performed.

Common implementation uses SPWeb.ApplyWebTemplate method to provision the starting point based on some out of the box site definition and then manipulates the created site using code. This is extremely flexible model, since you can easily update the code just by deploying new version of the used assembly… but wait… isn’t this almost the same model as for the web templates…

One implmentation of the provisioning providers is the PortalProvisioningProvider (Microsoft.SharePoint.Publishing.PortalProvisioningProvider) which is available in the SharePoint Server side, not from foundation. This provides the capability to create portal site templates, meaning hierarchy files.

Since provisioning providers require that the they are introduced using the WebTemp*.xml file, which has to be placed to file system, these are not usually supported for the cloud based services, like in the MS Online. This is also due the fact that the provisioning engine would not be standard and if all projects could implement their own provisioning engine, quality assurance required would increase enormously.

Notice also that this model is not recommended due future plans of SharePoint. Interface is not yet deprecated, but I' would not bet my business on this one, even though it might sound really compelling.

More information

More information on provisioning providers can be found from following locations:

Web template option in detail

Let’s cover the web template option little bit more detailed, so that overall model is understood properly. Following picture defines the process steps for creating new site based on the web template.

#	Description
1	When ever either site collection or farm scoped feature has been activated on the particular site with web templates, these templates are available from the Create functionality in similar way as site definitions. Web templates are deployed as features. If they are deployed as farm solution features, they are located in the 14 root folder, but obviously with Sandbox solutions, they are located in the content database. Element file define the preview picture, filtering options and the title visible in the create site functionality.
2	When web template is selected, new site is created using onet.xml file definition located in the same feature folder as the element.xml file, which was responsible of introducing it. Notice also that this onet.xml file can only have one Configuration element (with id 0).
3	In similar way as for site definitions, each feature referenced in the onet.xml file are activated in the order they are listed. When we create sub sites, web scoped features are activated, but if we use web template to provision site collection root site, also site scoped features are activated.
4	As part of the site provisioning process, the just created site is associated to some existing site definition, preferable to some out of the box site definition. This definition association is defined in the web template element file or in the WebTemplate element. This means that SPWeb.WebTemplate, SPWeb.Configuration and SPWeb.WebTemplateId properties are associated to some out of the box template. Meaning that we only used the alternative onet.xml instructions during site provisioning, but from that point forward, site is as any out of the box site… also when we upgrade the SharePoint deployment in future.

There are minor limitations in the web template onet.xml file, meaning that certain elements are not supported there. These elements are not usually used or they can be replaced using approach to use feature activations. Following elements of the onet.xml file are not available for WebTemplate onet.xml schema.

Module element – Used normally for oob site definitions to provision default.aspx and other initial files to site as part of the site provisioning engine. Shouldn’t actually be used for site definitions either. You can provision the necessary files using features, which are referenced in the onet.xml file. We’ll cover this in upcoming chapters more detailed. Note. This actually works, but it’s not supported based on MSDN article and shouldn’t be used anyway in onet.xml file, even though out of the box site definitions do so.
Components – Not commonly used element. The Components element specifies components to include in sites created through the definition.
- FileDialogPostProcessor – Represents an interface in Microsoft SharePoint Foundation that is used for Web views in the file dialog boxes and forms of document libraries
- ExternalSecurityProvider – Represents an interface that returns custom information about the security used in Microsoft SharePoint Foundation for indexing by a search crawler on a portal
ServerEmailFooter - The ServerEmailFooter element specifies the footer section used in email sent from the server.

So what does this mean? – in similar way as in the classic minimal site definition, we should concentrate on provision and configure everything from the features, which are associated in the onet.xml file.

As mentioned already earlier, we cannot staple features to web templates, but there’s actually no reasons to do this. Why? – well… since web template onet.xml file is only used provisioning time of the site and it’s completely supported to update the web template onet.xml, if any changes are required. This means that we don’t actually have valid business case for feature stapling support, since we can handle the update using alternative approach. This is not actually that big a deal, since actually feature stapling can be extremely confusing in large deployments, since there’s no easy way to solve which features have been associated to which site definitions.

One of the big advantages in web templates is the fact that we are able to provide new options to Create site functionality without requirement to deploy site definitions. Since web templates are also supported if they are deployed as Sandbox solutions, we can utilize them also in hosting scenarios, like in MS Online (BPOS). This is huge advantage, since it solves one of the classic limitations of providing new templates in shared environment scenarios.

Other advantages and extremely important thing to realize with web templates is the fact that we can utilize them even if we would use publishing features in our sites, meaning that we are creating WCM sites in SharePoint. There’s clear difference in this compared to site templates. Publishing features are not supported in site templates, but they are supported in web templates.

I’ve had quite a few arguments also concerning the missing support of creating hierarchies with web templates compared to site definitions. We'll, to be precise, you can’t define hierarchies with site definitions directly, but if you utilize the portal web templates, we can create multiple sites from one option. This requires configuration in the WebTemp*.xml file, which we don’t have for the web templates. This is indeed one limitation, but as with any area of SharePoint there’s always workarounds…

If you have requirement to create multiple sites at once, which is completely common scenario for example when we want to create the initial hierarchy of the some global intranet, you have few different options. If it’s one time or few times hierarchy creation, it’s actually much more efficient to define the hierarchy in PowerShell script and use that for creation. Other option would be to use similar approach as was used for Report Center creation back in 2007 version. This means that you create your hierarchies from features, which are associated to your onet.xml file. Those who are familiar of SharePoint object model, definitely knows how easily this can be done from feature receiver.

Whenever we need to reference to our custom web template for example for provision new site based on it, we’ll need to know the template name, which is defined for the WebTemplate element and also the GUID for the feature responsible of introducing that to SharePoint. So the format is as follows.

{FeatureGuid}#WebTemplateName
So example would be - {7642399e-798a-4eaa-9214-e80175e91463}#News

In following picture we provision new root web based on custom web template.

So, when we need to create site collection root site and create initial hierachy for the site collection, we can use following script. Notice that obviously your feature GUIDs and web template names will vary.

#set initial parameters
$name = "Vesku Corporation"
$url = http://www.contoso.com
$scOwner = "contoso\administrator"
$template = "{8642399e-798a-4eaa-9214-e80175e91463}#Home"

#Create site collection and provision the root web based on web template
New-SPSite -URL $url -Name $name -OwnerAlias $scOwner -Template $template

# Services section
New-SPWeb ($url + "/Services") -template "{7642399e-798a-4eaa-9214-e80175e91463}#Section"-name "Services"
New-SPWeb ($url + "/Services/Consulting") -template "{7642399e-798a-4eaa-9214-e80175e91463}#ContentLeft"-name "Consulting"

#Products section
New-SPWeb ($url + "/Products") -template "{7642399e-798a-4eaa-9214-e80175e91463}#Section"-name "Products"
New-SPWeb ($url + "/Products/Widget") -template "{7642399e-798a-4eaa-9214-e80175e91463}#ContentLeft"-name "Widget"

#About us section
New-SPWeb ($url + "/aboutus") -template "{7642399e-798a-4eaa-9214-e80175e91463}#Section"-name "About us"
New-SPWeb ($url + "/aboutus/company") -template "{7642399e-798a-4eaa-9214-e80175e91463}#ContentLeft"-name "Company"
New-SPWeb ($url + "/aboutus/directors") -template "{7642399e-798a-4eaa-9214-e80175e91463}#ContentRight"-name "Directors"

With web templates, there’s however one big disadvantage or case where they cannot be used. This is when your technical multilingual solution would be based on variation functionality. Variations can be used for providing multilingual solution for your solution when hierarchies between the different languages are identical (or almost identical). Variations work in a way that you select one language or hierarchy to be your primary language and other site hierarchies for are created based on this primary language.

In 2010, the variation functionality was changed to be timer job based, so there’s timer job, which ensures that the sites are copied properly between different variations, based on changes in root language. Since we don’t have any out of the box indication in sites that they have been created using web template, this timer job is unaware of the fact that template information in SPWeb object is not valid, since that refers only to some base site definition.

There’s unfortunately no workaround for this limitation concerning web templates currently, but let’s hope that variation functionality would be fixed to be aware of some indication on the used web template soon, maybe in some service pack. This does not however mean that you can’t do multilingual sites with web templates; it only means that you can’t use variations with web templates. Good examples of multilingual sites without variations is for example my old baby from back in autumn 2007, which has numerous different languages, like the following: www.kone.cn, www.kone.de and www.kone.ru.

Additional design guidelines for web templates

Now we have covered the key concepts of the web templates. Let’s also cover few guidelines for implementing these web templates in a way that we’ll follow good practices and increase the maintainability of our sites.

One of the key things to consider is the upgrade and maintenance model of the web templates. As experienced SharePoint developers know, the quality of the code and design is actually evaluated during the upgrade of these customizations. To improve maintainability and upgradability of your web templates or actually sites, created based on your web template, we should always create specific default web scoped feature for each of the web templates. Let’s clarify this more detailed in picture below.

#	Description
1	Obviously we can have miscellaneous amount of features referenced in our onet.xml, which are responsible of creating the required structures. You should however consider that could you associated your SharePoint project items actually to default feature, since each feature activation will have impact on the time required for site provisioning, so less is good, especially since we can associated the SPIs easily in VS2010.
2	Default hidden web scoped feature dedicated for the particular web template defined as the final feature under the WebFeatures section in the onet.xml file. This feature will be responsible of provisioning the welcome page of the site (default.aspx) and other structures required in the site. This feature should also stamp the identifier of the web template to site property bag. This identifier would be the WebTemplate name used of the particular, which is being created. We’ll demonstrate this in the example later in this article.

As mentioned, the default web scoped feature should be marked as hidden, so that it’s not accidently deactivated from user interface. This is also the feature, which we’ll use as part of our versioning model, since whenever we need to change the existing sites, we would have possibility to target our new customizations by versioning this particular feature. This way you can easily write the required feature upgrade actions and apply them to proper sites.

So the hidden feature is for versioning the already provisioned sites and the versioning of the actual web template can be just done simply by updating its onet.xml.

Note

More information concerning feature versioning support in SharePoint 2010 can be found from following locations:

MSDN – Application life cycle for SharePoint 2010 – video and presentation
MSDN – Upgrade features
Chris O’Brien – Feature Upgrade series – excellent series of articles concerning feature upgrade practices

One of the challenges in SharePoint 2010 web template provisioning and actually also in site definition provisioning is the fact that if you provision sub sites to already existing site collection, none of the site scoped features mentioned in onet.xml file are activated out of the box, like it was the case in SharePoint 2007 for site definitions. Someone might say that this functionality was already a bug in 2007 and now it’s fixed, but add us small challenge.

Quite often in projects you’d like to introduce some new functionalities after the initial version of the collection has been already created. Let’s image following case: We have existing corporate intranet and we’d like to add new events functionality to the intranet. Events functionality will include web parts, content types and some page layouts. It will also include some other configurations. Wouldn’t it be nice, if all of these required artifacts would be provisioned when I create the Events sub site, if they are missing.

Well in this case, due the required scope of the artifacts (page layouts, content types, web parts), we would be forced to first activate the features in certain order, to be able to create the sub site, which consumes them. Not necessarily big deal, but definitely also not optimal one either. Following picture defines solutions for this case.

Solution is to create web scope feature, which will verify that the required site collection scoped features are activated. If they are missing, feature receiver would activate those. This is relatively simple feature and only few lines of code, but it provides us a way to create completely isolated and independent web templates, which will create all required structures required for the particular functionality.

The only downside of this solution is the fact when we create sub sites from user interface, SharePoint 2010 will check that all site collections scoped features mentioned in onet.xml are actually activated. This means that this workaround works when you create your sites from PowerShell or if you don’t list your site collection scoped feature at all in the SiteFeatures elements. I completely understand the checking and verification, but it’s not implemented in most optimal way.

We’ll cover required code for this in our step-by-step guidance later in this article.

Step by step creation of new publishing web template

In this chapter, we’ll create new globally available web template, which will use publishing features to enable efficient content editing experience. We’ll do this steps by step, including the concepts defined above.

Setup initial structures

Let’s start by creating the necessary initial structures. Since my background in from 2007, I always start by thinking the overall layout of features and then I associate the required SharePoint projects items to them.

Start Visual Studio 2010 and choose Empty SharePoint project as your starting point

Personally I always start with empty project template, since you get the same wizards as from other templates when you add particular SharePoint project items (SPI) to your project.
In my case I named the solution as Contoso.Intranet.WebTemplates, so that it follows the general guidance for naming your SharePoint solutions uniquely

Choose the solution to be farm solution, since in this case we want to deploy our template globally. As mentioned earlier, you could also deploy your template only in site collection level.

Notice that we follow few naming guidance's for the features, which are creating. This is done to optimize the developer productivity by providing easy overall picture of the solution just by viewing the solution structure in Solution Explorer or in the Packaging Explorer. We’ll also hide all features, which should not be touched by end users to avoid any issues after initial deployment.

Let’s add a new feature to your project with following attributes. This will the default web scoped feature, which will be responsible of deploying welcome page and do other web (or site) specific configurations.

Title: Contoso.Intranet.WebTemplates - Site - Default
Scope: Site
Is Hidden: True
Feature node name: SitePublishingWebTemplateDefault

Let’s add another feature to your project with following attributes. This feature will be responsible of deploying all site collection scoped configurations, which the site will consume. In this case, this includes content types and page layouts. This feature will be also used as the versioning model for the existing sites, whenever there’s some changes required. With this I mean that since the feature is hidden it should be active and available in every site which were based on this upcoming web template and therefore we can easily upgrade them by using the new feature versioning capabilities in SharePoint 2010.

Title: Contoso.Intranet.WebTemplates - Web- Default
Scope: Web
Is Hidden: True
Feature node name: WebPublishingWebTemplateDefault

We’re still missing some required structures, so add third feature, which will be responsible of activating the default site collection scoped feature in case that we create sub sites. As mentioned above, this is due the fact that if you create sub sites, the site collection scoped features won’t be activated in SharePoint 2010 without little help. We’ll implement this as generic feature, so that

Title: Contoso.Intranet.WebTemplates - Web- Default
Scope: Web
Is Hidden: True
Feature node name: WebEnsureSiteScopedFeature

So at this point we have all features, which will be associated to actual web template, but we still need to create the feature responsible deploying it or feature, which will be responsible of telling for SharePoint that the template is available. We’ll do this with farm scoped feature, so that when ever the solution package has been deployed, there’s new web template available through out the farm.

Title: Contoso.Intranet.WebTemplates - Farm - Web Template deployment
Scope: Farm
Is Hidden: False
Feature node name: FarmWebTemplateDeployment

After this your Visual Studio Solution Explorer should look like in following picture.

Creating required SharePoint project items

In this business case, we’re creating new complete web template, which has also publishing features enabled. Quite often you’ll need to add new site columns to out of the box Page or Welcome Page content types (it would be long debate which one to use in WCM cases, so let’s not go there…) and therefore you’ll need to create your own content type. As you probably already know, creating new content types is relatively straight forward in the SharePoint 2010 development, so let’s not concentrate on details of getting these elements in, rather on the web template specific features.

I tend to group my SPI’s under SP folder and to specific sub folders to make the overall structure more easier to track. This is especially important in larger projects, which have multiple Visual Studio projects in them, but that’s a completely another blog entry (maybe in future :-).

We’ll nevertheless have the following folder structure as the starting point for following SPIs. We have already created the required custom content type and the page layout, which our web template will use by default.

Most important SPI is the welcome page module for the WebTemplate. This SPI will be associated to default web scoped feature, which will be activated as part of the site provisioning process. So how do we do that? Let’s click the Module folder and choose to add new Module element. We’ll name the module as MOPublishingtemplateWelcomePage.

You might again wonder the silly prefix for the module, but that’s also for increasing the developers productivity in larger projects. It will help to identify your individual elements in the Feature Designer and in the Packaging Explorer when you have tens of SPIs in your Visual Studio solution.

By default Visual Studio provides as example text file to be deployed, which we can completely remove, since we don’t use it in this case.

Since this is WCM site, we’ll need to have the default redirection page included in this module and to associate it properly to pages library with required attributes. Attributes in this case refer to page layout and content type which we want to use. We can copy the out of the box redirection page from SharePoint structures. This can be done by copying the default.aspx file for example from the following location: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates\PUBLISHING. Notice that we’ll need to copy default.aspx page, which is used out of the box for publishing sites, not for foundation sites (big difference).

Following thing is to update the elements.xml file of the just created Module SPI with the following values:

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Module Name="Home" Url="$Resources:osrvcore,List_Pages_UrlName;" 
          Path="MOWelcomePagePublishingWebTemplate">
    <File Url="default.aspx" Type="GhostableInLibrary" Level="Draft" >
      <Property Name="Title" Value="Welcome" />
      <Property Name="PublishingPageLayout"
                      Value="~SiteCollection/_catalogs/masterpage/
                      ContosoWelcomeLinks.aspx, Contoso Template" />
      <Property Name="ContentType" 
                Value="ContosoIntranetWebTemplatesPage" />
    </File>
  </Module>
</Elements>

Notice that we refer to our custom page layout (ContosoWelcomeLinks.aspx) and to custom content types (ContosoIntranetWebTemplatespage) in the properties. This will set the default settings properly for the page layout when the site is provisioned.

Since by default our custom content type is not available in the pages library, we’ll need to create additional SPI for it. This can be done by adding new empty element under the ContentTypeBindings folder. Element file should be updated as follows (obviously with the full GUID of the content type):

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <ContentTypeBinding ContentTypeId="[ContentTypeGUID]" 
                      ListUrl="pages"/>
</Elements>

Since SharePoint provisioning is based on the order of the element files in the feature definition, we’ll need to ensure that the content type binding SPI (CBPublishingSite) is listed above the welcome page SPI (MOWelcomePagePublishingWebTemplate) in the Feature Designer. If that’s not the case in your environment, remove the items from the feature and associate the in correct order (in larger deployments you might want to do this by updating the order inside the VS structure).

We are still missing one SPI, which will be responsible of adding the upcoming web template identifier to site’s property bag, so that after we have traceability on the used web templates and we can easily solve which template was used to provision particular site. As mentioned earlier, since the SPWeb.WebTemplate and SPWeb.Configuration properties will be “stamped” using some out of the box identifiers, those cannot be used to identify the template. Not a big deal, since it only requires one more SPI to be created.

Let’s create new empty SPI to new PropertyBag folder and update it content as follows. Notice how the use the new ProperbyBag element in feature framework to add entries to SPWeb property bag.

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <PropertyBag ParentType="Web">
    <Property Name="contoso.intranet-webtemplateid" 
              Type="string" Value="WTPublishingSite" />
  </PropertyBag>
</Elements>

This is the most important thing to remember in your web template development, so don’t skip this step, since otherwise you have no traceability on the created sites. Why is that so important? – For easy maintenance and upgrade models, this information could be required… there’s actually other ways to do same things, but this is easy and most straight forward way to stamp the item.

Remember to also ensure that the property bag entry SPI is associated to correct feature (WebPublishingWebTemplateDefault). Order does not actually matter in this case.

Now we have all the required SPIs for the web template in this case. Obviously you could have created other SPIs as well, for example to provision new list structures as part of the site provisioning. After this your Visual Studio Solution Explorer should look like in following picture.

Creating WebTemplate element

Since there’s no out of the box SPI template for web templates, we’ll need to create it using standard empty element. Let’s add new empty element under the WebTemplates folder and modify it as follows (in my case I named it as WTPublishingSite):

<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <WebTemplate
           Name="WTPublishingSite"
           BaseTemplateName="CMSPUBLISHING"
           BaseTemplateID="39"
           BaseConfigurationID="0"
           Title="Example Publishing Site"
           Description="Custom publishing web template"
           DisplayCategory="Contoso Publishing"/>
</Elements>

Notice how we customized the display group entry. This is the key introduction file, which can be used to control web template visibility for example that can it be used to create new site collections or not. If the web template has been deployed as farm feature and you only allow it to be used as sub sites, it would not be listed in the central admin as one of the options. This can be controlled by using SubWeb attribute (note. unfortunately there seems to be bug with this one at least with the RTM to august cumulative and the attribute doesn’t have any meaning at the moment – hopefully it will be fixed soon).

Notice also the BaseTemplateName, BaseTemplateID and BaseConfigurationID – as mentioned earlier, these have to refer to some existing site definition. We don’t use any of the content from that site definition, but this information is used to “stamp” the created web with some site definition identifier.

Only thing missing is the Onet.xml file, which actually defines in detail site provisioning tasks. In this case we are creating publishing feature based web template, so easiest way to get started is to copy the onet.xml file available from following folder: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates\BlankInternet\XML

Let’s copy that to WTPublishingSite SPI, right next to element.xml file in Visual Studio (drag and drop). First thing we’ll need to update is the properties of the onet.xml file to ensure that it’s deployed as part of the SPI. Just activate the file in the Visual Studio Solution Explorer and ensure that properties are as follows.

This will ensure that the file is packaged by the Visual Studio 2010 to the solution package, based on the associations in the Feature Designer. Following thing is to make the required updates on the onet.xml file. Onet.xml file structure for the web templates is completely identical as for the site definitions, except that there’s few elements, which are not supported. These elements are not actually that meaningful even for site definitions, since same functionality could be always provided using alternative approaches, like from feature receivers etc. I won’t go to details of the onet.xml structure too much, since that is a huge topic, but I’ll cover the key changes done in this case.

Let’s first start by removing cleaning up all unnecessary elements. We’ll get rid of following sections in the onet.xml file:

Document templates
- Not meaningful for demo and could be done from feature anyway
Other configurations than configurations –1 and 0 – meaning getting rid of configurations 1 and 2
- With web templates, the 0 is the only valid configuration
Modules
- Referring to those listed in the bottom of the onet.xml file, we don’t need these either, since we’ll provision the default page from feature as well.

If it would be out of the box team site template, we’d also get rid of all the list instances, since those can be done more easily from features.

Associating features to web template

Association of feature to onet.xml can be done easily as you might know from site definition development. We’ll first need to solve the identifier and scope of the feature to be associated and then we’ll just include that to proper location. Since we can activate site collection and web scoped features from onet.xml file, there are separate places for these. If you associate site collection feature, it has to be listed under the SiteFeatures element and all web scope features are listed under the WebFeatures element.

In this case we have three different custom features, which we should associate to proper places in the onet.xml file. By default you’d add the site collection scoped feature to SiteFeatures section, but since we want this feature to be activated automatically as part of our provisioning technique, we can’t do that. This is due the checking SharePoint does for sub sites. If template has site collection scoped feature, which is not activated, you’d get following error when you create the site from user interface.

So we’ll need to be little bit cleaver with our solution.

Let’s add a feature to our onet.xml file, which will be responsible of activating the site collection feature automatically, if web template is used for sub site creation. We’ll create the necessary code for the feature receiver in following chapter, but we can already add this required xml elements. Idea is that we can define which site collection scoped feature will be activated using feature properties. Since we want to ensure that the site collection scoped feature is activated before any web scoped features, we’ll need to add this as the first feature in the WebFeatures section, like in the following snipped.

<WebFeatures>
    <!-- Custom Site collection scoped feature activation -->
    <Feature ID="6e018893-bd28-44da-8048-a9752ca9d4ae">
      <Properties xmlns="http://schemas.microsoft.com/sharepoint/">
        <Property Key="SiteScopedGUID" Value="79b93e74-ce13-49d1-825b-5007feb8d481"/>
      </Properties>
    </Feature>

Notice that the above feature is custom feature, so it’s up to us which kind of feature properties are implemented.

Following step is to add the provisioning of welcome page, which we implemented in previous chapter. Since we want all structures be ready, before we provision our welcome page and optionally do some additional customizations from feature receiver, we associate this feature as the final feature to WebFeatures section, like in the following snipped.

            <!-- Welcome page provisioning for the web template -->
            <Feature ID="5bd39d1e-9e39-4e4f-932c-eb393b5454a4" />
        </WebFeatures>
        <Modules />
    </Configuration>
</Configurations>

Notice that this is also the feature, which can do any customizations for just created site; since possible feature receiver in this feature is executed after all other configurations are applied. So for example if you’ll need to do some web part connections for the welcome page, this could be done in this feature, since welcome page is first deployed and then our feature receiver is executed.

Adding code for the feature receivers

Let’s move to add the necessary code for our feature receivers or actually to only one in this case. Required code was to activate the site collection scoped feature, which has been referenced in the WebFeatures section. So let’s right click WebEnsureSiteScopedFeature in our project structure and create the required feature receiver for the feature.

You can comment out other methods, than the FeatureActivated method, which is executed when feature is activated as part of the site provisioning. Let’s update that as in the following code example.

public override void FeatureActivated(
                       SPFeatureReceiverProperties properties)
       {
           //Ensure that scope is correctly set
           if (properties.Feature.Parent is SPWeb)
           {
               SPWeb web = (SPWeb)properties.Feature.Parent;
               foreach (SPFeatureProperty property 
                               in properties.Feature.Properties)
               {
                   Guid featureGuid = new Guid(property.Value);
                   //Verify feature status
                   SPFeature feature = web.Site.Features[featureGuid];
                   if (feature == null)
                   {
                       //Activate site collection scoped feature, 
                       //if requested and not currently activated
                       web.Site.Features.Add(featureGuid);
                   }
               }
           }
       }

So what do we do in the code? – We’ll read the GUIDs from the feature properties and activate, if they are not activated. This way we can activate site collection scoped features also from web scope feature, which provided us the way to encapsulate all features part of the web template to single provisioned package. You might want to improve the error handling and logging in real scenario, but this is fine for demonstration purposes.

Testing and ensuring that it’s working

So how do we test the functionality? You actually don’t want to just start debugging with default settings, since Visual Studio 2010 would activate the site collection scoped feature for you automatically based on the ActivateOnDefault setting of the particular feature. This is nice for debugging point of view, but that’s not actually the way it works in real life or when you deploy your customizations from development environment to production environment. ActivateOnDefault attribute for site collection scoped features is only valid for Sandbox solutions, but not when farm solutions are used, so let’s try to verify the functionality using alternative approach.

Before deploying, verify that you have No Activation as the Active Deployment Configuration for your Visual Studio solution, so that features are installed, but not activated. This can be controlled from project properties. Deploy your customization or you can also start by debugging for verifying the functionality.

Not that compelling, but demonstrates the web template functionality quite nicely, so it’s cool template – Yes I’m a geek.

Example project found from reference list will also contain example web template for custom collaboration or team site. Collaboration example has been only modified slightly compare to out of the box team sites, but it still has the same upgrading or maintaining support etc. There’s also example of adding web parts to welcome pages from the default web scoped feature. Nothing actually new there for web templates, meaning that same model as for site definitions will work there as well.

Web Template FAQ

In this section we’ll cover few of the most common questions concerning web templates. Most of the questions have been already covered more detailed earlier, but just to summarize them.

“I associated my web template to some existing site definition, what is used from the root site definition’s onet.xml file?”

Absolutely nothing. Onet.xml of the web template will completely replace the referenced site definition during provisioning. Model is actually identical as if you would be using the new CustomSchema attribute available for list instances.

“When I use site definitions, object properties will get recorded correctly (SPWeb.WebTemplate etc.), so I’m unable to track which sites were created using which template. This is huge disadvantage on web template. “

That is true, but nevertheless you’ll need to write some logic to access those properties in your custom code. It’s as easy to access the property bag of the SPWeb as long as you remember to add the information there as suggested earlier in this article.
You actually never know what features have been activated on top of the initial site definition, so the advance of having exact identifier available is not actually even that important. In upgrade or maintenance scenarios, we’ll nevertheless need to figure out the actual features which have been activated.

“Why wasn’t the requirement to stamp the SPWeb to site definition removed or support to use the web template identification information added for that? “

This is due the backward compatibility requirements. If these would have been completely removed, there would have been lot of the custom code developed by you and me, which would not worked in SharePoint 2010. These properties are also one of the core properties of the whole SharePoint platform, so changing those would cause huge quality assurance activities.
Those of you who been working in R&D definitely understand the historical legacy products are carrying – let’s not go too much details on this.

“You can use the WebTemp*.xml to define the portal hierarchy to be created using the portal site template approach. If I use web template approach, there’s no way to do the same.”

True, since the WebTemp*.xml file is not created or required, since all web template related files are actually stored in the database and WebTemp*.xml file changes requires deployment of the files to file system of the servers.
As covered earlier in this article, there’s two different workarounds for this. For in-frequent use, you should be using PowerShell for the hierarchy creation and if you constantly create multiple sites at once, you can easily achieve this from feature receiver.

“What about BPOS (MS Online) and generally other hosting companies? “

Generally, like for BPOS, web template is supported way to deploy your customizations, since that way individual sites can be more easily upgraded in future versions. If you create site definitions to some deployment, migrating that to cloud could be enormous effort. By utilizing the web template approach, you provide more flexibility for that deployment also in long run.

“I heard that WebTemplate element is designed only for Sandbox solutions, is this true? “

No. WebTemplate element is part of the feature definition schema and it’s available also for full trust solutions. References to Sandbox solutions are only caused by the fact that it has been the most visible usage for the WebTemplate element in public demos.

“When I’m creating my web template I need to decide to which out of the box site definition it will be associated. Does the definition actually matter, couldn’t I choose any of them? “

Yes you could, but it’s better to choose as close as possible similar site definition as your custom web template. Meaning that if you create publishing web template, associate it to out of the box publishing site definition and similarly when you’re creating for example enhanced team sites. This is just due the fact that it will most likely help in your future upgrade to following SharePoint version.

“Provisioning providers can be as easily updated as web templates, why would I use web template model? If I create my site based on some out of the box site and then activate what ever is required in my own provider? “

Since provisioning provides will be completely based on custom code, they indeed can be easily upgraded, but this comes down on standardization of development and future considerations concerning deployment. When developers are moving between different companies and projects, it would be good that we would have standardized process for site provisioning. If you base your solution to provisioning provider, it’s custom code, which is not standard.
Other consideration is the deployments future. Web templates are also supported usually by hosting providers (like MS Online), but provisioning providers not. Even though requirement for cloud based solution is not in the objective of the first release, it doesn’t mean that it couldn’t be popping up in future.

“Somebody was discussing this concept called feature groups – which would be excellent way to just define what features would be activated when site is created. Onet.xml is so complicated, why can’t this be more simplified“

Who knows what the future brings (some do, but they are not telling… :-), but basically if you follow up the guidance of provisioning everything from features, not from onet.xml file, you actually have similar functionality. You only need to concentrate on what features will be activated and on which order. It’s not even close rocket science… especially since I got it…

“I heard that variations doesn’t work with web templates – is this true?”

Yes, this is really unfortunate limitation, but it only affects the variations and it’s actually quite understandable, since there’s no out of the box way to indicate that site was created using custom web template. Variation functionality is dependent on the site definition information available from the SPWeb level and it has no glue that the site has been created using alternative onet.xml file.
This does not however mean that you couldn’t do multilingual sites, since variation is only way to do this and quite often it’s not usable due differences between the hierarchies in language versions.

Summary

So, when should I be using web templates? – This is commonly asked question. Answer is actually extremely simple: Whenever possible. Web template provides highest flexibility for maintenance and easy upgradability support. It provides also easy way to to provide templates only in site collection level, not always throughout the farm, like with site definitions. They can be freely updated based on new technical and business requirements.

If for some reasons you still choose to use site definitions, you’ve already impacted enormously to the future of the particular deployment. What if in long run they’d like to move to use some cloud service? – if site definitions have been used, it’s impossible or you have to create separate migration project first to get the content from custom definitions to web templates. Those who’ve been involved since SP2003, can remember those jolly upgrade projects we had from 2003 to 2007.

Let’s try to avoid unnecessary complexity and consider the consequences of our decisions we make with custom architectures and customizations.

“The purpose of software engineering is to control complexity, not to create it.” – Dr. Pamela Zave

References and links

Here’s few good links concerning web template related information.

MSDN – SharePoint 2010 Advanced developer training – Video and presentation
- Web template content starts from around 20:00 and don’t get fooled on the fact that we only demo sandbox solution
MSDN – Web Templates
SkyDrive - Example solution package
- Example package, which demonstrates the structures introduced in this blog entry. Contains example of publishing web template. Will be updated later with other examples as well.
Mirjam van Olst - Using the SharePoint 2010 WebTemplate Feature Element for creating Site Templates
Chris Beckett – SharePoint 2010 Custom Site Templates

Note. I’ll be updating this blog entry based on all the questions and comments coming in (rather in blog post, than to email please)… and there’s few things which I didn’t have time to include to this post, which I’d love to get updated soon…

New advance SharePoint 2010 training material released

2010-05-12T14:50:18Z

We just released new SharePoint 2010 training materials to MSDN and TechNet. Material is also downloadable as videos and PowerPoint presentations.

[Updated 16th of May – Direct links to IT pro trainings added. Also content concerning Channel 9 trainings included.]

Modules

Material contains around 40 different modules, which length varies from 30 to 100 minutes. Overall time for all of the modules is around 41 hours (22 hours in developer, 19 hours of IT Pro). There’s lot of interesting topics covered.

Here’s introduction and links for both of the tracks.

Developer

“For developers, SharePoint 2010 provides a business collaboration platform to rapidly build solutions and respond to business needs. SharePoint 2010 Advanced Developer Training offers technical training as self-paced modules and hosted labs for SharePoint 2007 professionals who want to upgrade their skills to SharePoint 2010.” - SharePoint 2010 Advanced Developer Training

You can also download presentations directly from Microsoft Download site.

IT Pro

“For IT professionals, SharePoint Server 2010 offers enhancements to drive productivity, a scalable unified infrastructure, and flexible deployment. SharePoint Server 2010 Advanced IT Professional Training is a deep technical learning series for current SharePoint Server 2007 professionals who are looking to upgrade their skills to SharePoint Server 2010” – SharePoint Server 2010 Advance IT Professional Training

You can also download presentations directly from Microsoft Download site.

Instructors

This was extremely interesting engagement and we worked with many extremely skillful instructors. Here’s the list of persons, who owned modules in this training.

Mark Kashman, Product Manager, Microsoft
Steve Pescha, Principal Consultant, Microsoft
Chris Gideon, Principal Premier Field Engineer, Microsoft
Todd Carter, Principal Premier Field Engineer, Microsoft
James Petrosky, Principal Consultant, Microsoft
Vesa Juvonen, Principal Consultant, Microsoft
Shane Young, MVP, SharePoint 911

Global tour

During past year we also had global tour to do trainings for partners and customers. We visited following cities with little bit different set of instructors: Seattle, Atlanta, Dallas, Amsterdam, Berlin, Bangalore and Singapore. Thanks for all participants and instructors from my behalf. Personally I had excellent time on the numerous locations I visited.

I also want to thank the local vendors for making sure that all of the logistics were running smoothly in each of the locations.

Thanks for everyone being involved for making this possible and such a success. Hopefully you find the available recordings useful and they help to make successful deployments and pleased end users.

Channel 9 SharePoint 2010 developer videos also released

Check also the newly released Channel 9 SharePoint developer content. There’s new videos and content available. This content was created together with the Critical Path Training instructors (mainly Andrew Connell & Ted Pattison), who are also mainly responsible of the recorded content. Paul Stubbs has been one of the drivers for this content internally. You can read introduction from following blog entry:

From Paul’s Blog - SharePoint 2010 Developer Training Course

What’s the relationship of these two developer training materials? – Materials are originally based on same root content, but they were differentiated from each other long time ago. Both training materials have modules, which cover similar topics, but there’s lot of different content and demos in each of them. There’s also numerous modules, which are not overlapping between these two materials. I strongly suggest to check them both.

How to – SharePoint 2010 – JS client object model and UI advancements

2010-02-25T17:20:09Z

This blog entry shows how to utilize the new UI functionalities available in the SharePoint 2010 and how to use JavaScript object model to manipulate the site structure.

Create initial structure in VS2010

The first step is to create the Visual Studio solution. In this case we will create a new Empty SharePoint project with name ClientOMUIActions.

Since we will be adding Visual Web Part to the project, we will need to use the farm solution option.

The following step is to add a new Visual Web Part item to the project – let’s name it UIDemo

Add dialog integration

In this case we need to add the dialog framework integration code to our visual web part, we can definitely use the same model in ribbon buttons, if required. Let’s add the following script element to the Visual Web Part canvas.

</script>

Here are a few things from the code worth pointing out

Notice the url property, which is set for the DialogOptions. This is the target url to be shown in the dialog. In this case we point to the custom application page, which we will create in upcoming steps
Notice also how to set the delegate for call back. In this case we define that when ever the dialog is closed, CloseCallback function will be called
Notice how we check the return value usign SP.UI.DialogResult and act upon the response
messageId variable will be used later, so let’s add it now but use it later

The following step is to hook up JavaScript to our link, so let’s add the following to the Visual Web Part canvas as well so that when ever the the link is clicked, our dialog code is invoked.

<br /> <a href="Javascript:OpenDialog();">Start UI and client om demo</a>

Let’s test the functionality by deploying the web part to the portal and clicking the link. We should see following popup opened up.

This error is due the fact that we haven’t implemented our dialog page yet. Let’s close the dialog by clicking the close button from the top right corner. You should see the following alert window shown.

Modify application page

The following step is to create and modify the application page to use little bit nicer UI. We also need to add some code to provide response value correctly back to the parent window. Let’s add a new application page to our project named ListCreationPage.aspx.

Since we want to use the SharePoint style of rending of the dialog content, let’s add the following registration line on the top of the page, just above the Page statement. We will be using the controls to provide a nice SharePoint like popup “feeling”.

<%@ Register Tagprefix="wssawc" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register TagPrefix="wssuc" TagName="InputFormSection" src="/_controltemplates/InputFormSection.ascx" %>
<%@ Register TagPrefix="wssuc" TagName="InputFormControl" src="/_controltemplates/InputFormControl.ascx" %>
<%@ Register TagPrefix="wssuc" TagName="ButtonSection" src="/_controltemplates/ButtonSection.ascx" %>

Following step is to add the required JavaScript to handle the call back functionality. Let’s add following script elements to PlaceHolderAdditionalPageHead content place holder.

I’ll point out a few of the elements from the code

We create two separate functions – one for the OK click event and one for the Cancel event.
Notice how to pass the DialogResult enumerator value based on our response
In the OK function, we also take the value from existing textbox on the page, which is passed as a parameter to commonModalDialogClose function

Following step is to create the actual page layout. You’ll need to add following to the place holder called PlaceHolderMain.

Few pointers again on the code to clarify what we just did

We use the InputFormControl and InputFormSection controls to provide a nice look and feel for our popup
In this case the buttons are html buttons, since we are not using code behind code to do anything in this case
Notice how we call the JavaScript functions we created in the previous step from the button clicks

Now that the dialog page has been implemented, let’s test the functionality. You should get following dialog.

Now if you click OK, you should see following alert shown – this confirms that our dialog callback is working properly.

Add notifications

Let’s start using the notifications, to replace the “ugly” alerts, which we are currently using. SharePoint 2010 provides a really nice notification framework, which we can easily utilize. Let’s update the CloseCallback function on the visual web part as follows.

// Dialog callback
function CloseCallback(result, target) {
    if (result == SP.UI.DialogResult.OK) {
        //Get id
        messageId = SP.UI.Notify.addNotification("<img src='_layouts/images/loading.gif'> Creating list <b>" + target + "</b>...", true, "Dialog response", null);
        //Create list using client OM
        //createList(target);
    }
    if (result == SP.UI.DialogResult.cancel) {
        SP.UI.Notify.addNotification("Operation was cancelled...", false, "", null);
    }
}

Again here’s a few things to point out from the code

We use the SP.UI.Notify.addNotification function to notify the end user based on the action in the dialog.
Notice how we also use the callback value in the message (target parameter) – in this case we are showing the list name to be created
We can use html for the notifications – in this case we added a small gif animation in the OK button click
Creating list – message is shown using sticky mode (second parameter on the function call) and we store the notification identifier, so that we can show the message until the the list has been actually created
Notice the commented CreateList function call – we’ll add this in following step

Now if you try the functionality again, you should get following messages shown on the user interface, depending on the button you clicked.

Add JavaScript client object model code

Objective was to create new list using Client object model when ever OK is clicked. Since the JavaScript OM is by default available in any SharePoint page, we can just add the following functions.

//Actual JS client side object model calls
function createList(listName) {
    //Create client context.
    var clientContext = new SP.ClientContext();
    var oWebsite = clientContext.get_web();

    //Let's create list creation information object
    var listCreationInfo = new SP.ListCreationInformation();
    listCreationInfo.set_title(listName);
    listCreationInfo.set_templateType(SP.ListTemplateType.announcements);
    listCreationInfo.set_quickLaunchOption(SP.QuickLaunchOptions.on);

    this.oList = oWebsite.get_lists().add(listCreationInfo);

    //Let's create also new item to the list to be created
    var itemCreateInfo = new SP.ListItemCreationInformation();
    this.oListItem = oList.addItem(itemCreateInfo);
    oListItem.set_item('Title', 'Example item for ' + listName);
    oListItem.set_item('Body', 'Hello seminar audience. From list ' + listName);
    oListItem.update();

    clientContext.load(oListItem);
    clientContext.load(oList);

    //Execute the actual script
    clientContext.executeQueryAsync(Function.createDelegate(this, this.onQuerySucceeded), Function.createDelegate(this, this.onQueryFailed));
}

//Called if client side OM is successful
function onQuerySucceeded() {
    //Remove the 'creating' event notification
    SP.UI.Notify.removeNotification(messageId);
    //Add 'created' notification as non sticky
    SP.UI.Notify.addNotification("List <b>" + oList.get_title() + "</b> created...", false, "", null);
}

function onQueryFailed(sender, args) {
    //Remove the 'creating' event notification
    SP.UI.Notify.removeNotification(messageId);
    //Shown in case of error on the JS OM call
    SP.UI.Notify.addNotification("Operation was cancelled...", false, "", null);
}

Remember also to uncomment the createList call from the CloseCallback function

//Create list using client OM
createList(target);

Here’s a few things again from the code

Notice how we first get the client context, before we start doing anything
The executeQueryAsync method call actually invokes our modifications on server side from the JavaScript – we set two different function callbacks here, depending on the result. During this call, the requested actions are sent to the server side handler for manipulation
In both callback functions we remove the previously added sticky notification, before adding new one to indicate the result

If the changes have been applied properly and you now test the dialog functionality, after providing the list name and clicking OK, you should get following message after a while.

If you navigate to All Site Settings, you can see that the new list with single example item has been created.

Dialog framework and code behind code in dialogs

In the example we just went through, we used only client side code, but it’s quite common that you’ll need to execute also server side OM code as part of the dialog operations. In that case after you have executed any server side code, you can execute the following code to close the dialog and return results back to caller window.

//Close the dialog - we are good to go
this.Page.Response.Clear();
this.Page.Response.Write(string.Format(CultureInfo.InvariantCulture,
"<script type=\"text/javascript\">window.frameElement.
commonModalDialogClose(1, '{0}');</script>", ListItems.Count));
this.Page.Response.End();

Notice following from the code

Two different parameters are passed to the commonModalDialogClose JavaScript function
First one defines the response code – in this case it’s 1, which means success (same as SP.UI.DialogResult.OK). You can also return 0, which would mean cancel
Second parameter can be used to pass any relevant information for your application. In this case we return the count of items in the ListItems variable, which we utilized in our server side code.

Summary

As I wrote in the beginning of this blog entry, we can definitely use similar code and approach also from ribbon buttons, which makes extending of the ribbon extremely easy. SharePoint 2010 provides excellent web 2.0 platform for developers. For more information about the new capabilities, check MSDN.

Hopefully this was useful – btw. Due miscellaneous reasons, the full package won’t be unfortunately available at least for a while…

SharePoint 2010 team development environment

2010-02-01T16:14:12Z

SharePoint 2010 release date is closing (H1/2010) and there is huge interest on the product capabilities. There’s already few ongoing projects, which are scheduled to be released on H2/2010 and using currently beta 2 version for development.

One of the key questions currently asked, is the setup for team based development. This blog entry defines few alternatives and some recommendations based on personal experiences.

So how do you actually setup large development teams in efficient way, so that the investments done for the development environment are reasonable? As it has been documented, the hardware requirements will increase compared to 2007 at least in some level. Personally I’m mobile person, so I’m using my laptop with 8Gb and dedicate 5.5GB for the development VM. For storage of the VMs, I use secondary SSD hardware (speed is brilliant), but when we are setting up team based development, this is not the only option.

What about when you actually setup development environments for example for 40 developers?. We do have few options…

Running SharePoint from developer’s laptop or desktop – few options here
Running development environments from virtualized hosts

Let’s go the options one-by-one.

Client side setup to client OS

Basically each developer is having their own SP environment as client side OS install. VM is connected to corporate network to have access to centralized source control system. VM installation can be scripted to have new environment ready to be used within less than one hour. For setting up these, you can use either dedicated AD with network access to corporate net or use corporate network accounts for VM. Details on the setup obviously this depends on corporation policy.

Advantages

Flexible development without necessarily constant requirement to access the corporate network
Easy access of development, no delays concerning VM booting up etc.

Disadvantages

If developer is involved in multiple projects, possibility to accidently create dependencies between them
No project based software setup - for example office client version
Requires heavy hardware for each developer’s computer - 8Gb memory and secondary fast hard drive (at least 7200RPM) would be good for productivity
Cannot be centrally managed
- Synchronization and patching of the environments can be difficult
High hardware requirements for each lap top or desktop – hardware is not efficiently utilized during vacations, sick leaves etc. – “hardware utilization shortage”

Client side setup using virtualization

Similar mode as above, but using virtualization software.

Advantages

Flexible development without necessarily constant requirement to access the corporate network
Virtualization provides snap-shot support
Each developer can dedicate one VM per project – each project can create the base setup (SPF or SPS) + browser support + client versions (office 2003/2007/2010) etc.

Disadvantages

Requires heavy hardware for each developer’s computer - 8Gb memory and secondary fast hard drive (at least 7200RPM) would be good for productivity
Cannot be centrally managed
High hardware requirements for each lap top – hardware is not efficiently utilized during vacations, sick leaves etc. – “hardware utilization shortage”

Virtualized host setup

Let’s setup multiple centralized VM hosts, which can be even dedicated to single projects. This way we can have even tens of VMs on one of the environments, since if we only keep active those VMs, which are actually used, we can free flexibly resources. In our projects (MCS Finland), we’ve been successfully utilized this model already in 2007 development – and of course for 2010 development as well. VM hosts have to have more expensive hardware, but it’s still much more cost efficient, compared to investments for each developers.

Whenever projects are switched to maintenance mode, we can degree the amount of hardware used for single project – which will adjust the developers work as well. In our case, we have two primary development servers, where on both we have around 25 VMs, from which approximately 5-6 are running at the same time. This model has been extremely suitable for up to 10 persons with developers roles in 5-7 different projects.

How many developers can utilize on VM host? – depends on the hardware and virtualization engine, but 5-6 is easily doable even with relatively simple setup. Biggest bottle neck will be file IO – so disks will determine how many developer VMs you can actually have in single VM host. Obviously memory required in the host servers is also one of the key considerations.

In this case, heavy hardware is required, but you can also manage and phase your investments based on the projects for SharePoint 2010. Whenever new 300-500 man day project starts, buying 4500$ hardware for it, is not a big deal… depending of course on your profit model – after the project, server can be utilized also by others. “Hi manager, so to be able to do this 300.000$ project, we need to have initial investment of 4500$ - ok?” – “Definitely, since we want the do the project .”

Advantages

Centrally managed environments
No high hardware requirements for developers own machines - used only for office content etc.
Efficient utilization of the hardware based on project demand – easy scale up and out
Easy setup for more larger farm setups for testing purposes

Disadvantages

Requires additional resources or roles to manage the centralized virtualization server – just to ensure that it’s online and available all the time
Possible single point of failure – depends on virtualization model and software used

Additional considerations

For overall costs, we also need to include the dev integration server and possibly also the setup used by test team. If we are using centralized model, with VM host, we can start and stops these environments as well easily.

Dispute the fact that if the development would happen on individual laptops or desktops, we need to have at least few VM’s running to imitate the production deployment. So virtualization has be nevertheless done. Obviously everything depends on project size and requirements, but for enterprise projects, we need include the environment requirements and setup for the plans concerning the overall project / portal life cycle planning. This planning has not changed that much from 2007, expect the new possibilities to manage and update already deployed functionalities in production environment.

Summary

Centralized virtualization model is definitely the most cost efficient options. This way the developers should be able to utilize their current lap tops for client side tasks (outlook, power points, docs), but actual work is done on the virtualized hosts. Servers can be easily used also to host other requirements, like if there’s projects where we need to integrate OCS and Exchange, we can add those as additional server to virtualization rack and they are good to go – we can relatively easily created internal networks and farm based installations for testing purposes.

Key cost savings with the centralized model are also dependent on the fact that the hardware is efficiently utilized – if some of the developers are on vacation, those VM’s can be stopped and resources can be allocated to other projects. This provides lot of flexibility and cost efficient way to utilize the investments done.

SharePoint 2010 Virtual Machine for customers & partners now available

2010-01-27T01:07:37Z

We have now released downloadable environment to get up to speed with SharePoint 2010. You can download the VM from the following address.

http://www.microsoft.com/downloads/details.aspx?FamilyID=0c51819b-3d40-435c-a103-a5481fe0a0d2&displaylang=en

Following chapters are directly from the download page, but edited for more readable format.

[IMPORTANT] – You’ll need to import the VM to Windows Server 2008 R2 Hyper-V, so that the network adapter settings will remain the same, otherwise you’ll run into issues concerning activation of OS and Office Client.

You can also download additional training material from the following links for SharePoint 2010 and for Office 2010. These include presentations and hands on lab material for developers.

SharePoint 2010 – http://channel9.msdn.com/learn/courses/SharePoint2010Developer/
Office 2010 - http://channel9.msdn.com/learn/courses/Office2010/

Overview

This download contains a two Virtual Machine set for evaluating and demonstrating Office 2010 and SharePoint 2010. Virtual machine “a” contains the following pre-configured software:

Windows Server 2008 SP2 Standard Edition x64, running as an Active Directory Domain Controller for the “CONTOSO.COM” domain with DNS and WINS
Microsoft SQL Server 2008 SP2 Enterprise Edition with Analysis, Notification, and Reporting Services
Microsoft Office Communication Server 2007 R2
Visual Studio 2010 Beta 2 Ultimate Edition
Microsoft SharePoint Server 2010 Enterprise Edition Beta 2
Microsoft Office Web Applications Beta 2
FAST Search for SharePoint 2010 Beta 2
Microsoft Project Server 2010 Beta 2
Microsoft Office 2010 Beta 2
Microsoft Office Communicator 2007 R2

Virtual machine “b” contains the following pre-configured software:

Windows Server 2008 R2 Standard Evaluation Edition x64, joined to the “CONTOSO.COM” domain
Microsoft Exchange Server 2010 Active directory has been preconfigured over 200 “demo” users with metadata in an organizational structure.

All of these user profiles have been imported and indexed for search within SharePoint Server 2010, with “contoso\administrator” granted administrator permissions.

SharePoint Server 2010 has been configured in a “Complete” farm using Kerberos authentication and the default SQL Server 2008 instance for data, and has a site collection created using the Team Site template at http://intranet.contoso.com/ and a FAST Search Center at http://intranet.contoso.com/search/.

Performance Considerations

If possible, unpack and run the VM image on a separate, fast hard drive (7200 RPM or better) from the operating system of the host machine. If this is being done on a laptop, a second internal drive or external eSATA drive works best, though USB 2.0 (make sure it's 2.0, 1.1 is too slow) or Firewire is acceptable. For absolute best performance use a second internal SSD drive.

System Requirements

Supported Operating Systems: Windows Server 2008 R2; Windows Server 2008 R2 Enterprise; Windows Server 2008 R2 Standard

In order to run this demo you will need the following: - Windows Server 2008 R2 with the Hyper-V role enabled. - Drive Formatting: NTFS - Processor: Intel VT or AMD-V capable - RAM: 8 GB or more recommended - Hard disk space required for install: 50 GB

Setting up your environment

Start Hyper-V Manager from Control Panel -> Administrative Tools
Confirm that the local host machine appears in the Hyper-V Manager list and select it if not already done
Under Actions, click Virtual Network Manager…
Confirm that you have created an Internal virtual network named “Internal”. Internal networks limit connectivity to only VMs and the host. If a suitable not, create one now using the following steps:
1. Click on Virtual Network Manager in the Actions pane
2. Choose New virtual network in the Virtual Networks pane
3. Choose Internal from the type list and click Add
4. Enter a name of Internal and click OK
5. Start menu -> right-click Network –> Properties
6. Click Change adapter settings
7. Find the adapter with a description of Internal, right-click and choose Properties
8. Double-click on Internet Protocol Version 4 and enter the following values:
  1. IP address: 192.168.150.6 2.
  2. Subnet mask: 255.255.255.0
  3. Default gateway: (leave blank)
  4. Preferred DNS server: 192.168.150.1
9. Click OK
10. Close the Virtual Network Manager dialog.
Under Actions, click Import Virtual Machine…
Use the Browse button to select the folder where the virtual machine package was extracted.
Click Import and wait for the Import to complete – the import status will appear in the Operations column
Select the newly imported virtual machine and click Settings in the right pane of the Hyper-V Manager
Confirm (and correct if necessary) that the Network Adapter is connected to the Internal network from step 1d.
Close the virtual machine Settings dialog.

How do we do SharePoint development, including TFS integration?

2009-10-25T15:32:18Z

There’s lot of information available concerning development processes, automated builds and continuous integration in SharePoint development using Team Foundation Server, but unfortunately most of the information is in relatively high level or just concepts, but details are missing. It’s also fairly common misconception that setting for example automated build with TFS is difficult – it’s not.

Following chapters defines the practices we use in MCS Finland during development and for setting up the automated daily builds from TFS for enterprise projects. We will concentrate on the development process and setting up automated build process, but I’ll give some additional context from the project management point of view as well.

This content applies both SharePoint 2007 and 2010 development. There are minor changes and improvements with SharePoint 2010 development, which are pointed out.

In this blog post, we cover following topics

Development process
Visual Studio solution configuration
TFS side configurations
Automated testing environment setup

Development process

Following picture defines in high level the process we used for our enterprise projects. Actual details depends of course on the project size and project team. Actual process or methodology depends as well on the project, but process is always based on the agile approach with numerous iterations. Usually methodology used can be considered as adaptation from the SCRUM.

#	Step	Description
1	Requirements and tasks	Project requirements and tasks are collected from project owners
2	Collecting tasks to TFS	All tasks to be accomplished (also documentation) are entered as tasks to the team foundation server. Tasks are divided to iterations based on the initial plan of the project.
3	Virtualized development environments	All development environments are virtualized for easy management. Standardized base image has been created, which can be setup to server in matter of minutes. We commonly used centralized box to host our virtualized environment, but this depends also on project. Some consultants have 8GB on their laptop, making it as more appropriate and flexible hosting environment using Hyper-V.
4	Integration and testing servers	Separate testing servers are part of the project setup, which are used to verify the delivery before installing that to customer environment. Automated builds are used and depending on the project, automated testing is being done, using process defined later in this blog post.
5	Evaluation of status	Daily builds are being validated and based on the status and iteration schedule new deployments are being installed to the customer’s quality assurance environment.
6	Quality assurance testing	Customers can follow up the progress of the projects and give instant feedback, if there’s something to change. Release cycle to customer environment depends based on project, but is approximately two weeks to ensure that there’s constant dialog on the functionalities being developed. Quality assurance environment is also used as the acceptance testing environment, when production release is planned to be done.
7	Change requests and feedback	Feedback and change requests from the quality assurance environment are tracked to team site and entered to TFS system for developers to see the possible changes and new tasks. All incoming change requests are prioritized and scheduled to iterations based on discussions with project owners.
8	Production installation	When first release can be done, QA environment is used for acceptance testing and decision to move forward is done.
9	End user feedback	Since quite rarely projects end on the first production release, feedback and tasks are obviously collected from the end users to be processed to change requests and actual development tasks.

Iteration and production release count obviously depends on the project.

Visual Studio Solution configuration

There are few things to do in the Visual Studio Solution level to enable automated builds, if you use Visual Studio 2008 in development. By default Visual Studio 2008 does not understand the solution packaging concept, so we need to enable this by modifying VS project file. Also by modifying the project settings, we can improve our development experience.

In our case the standard VS2008 project structure usually looks something like following. There’s few things to notice from the solution structure.

Code is divided to multiple projects based on their usage models
- ApplicationLogic – contains business logic of the project, including all actual code manipulating data of the lists etc. If patterns and practices models are used, services, repositories etc. are placed here as well.
- Data – this is project for the data objects, which are used to transfer information between different solution layers. For easy manipulation in the UI layer, all code is transferred to data objects, rather then transferring actual SharePoint objects. This also helps in unit testing.
- FeatureReceivers – this project has the custom feature receiver code. Code is separated, since feature receivers have to be placed to GAC in every deployment scenario.
- Resources – this project contains the 12 hive files
- Solution.Assemblies – project to create the *.Assemblies.wsp solution package
- Solution.Resources – project to create the *.Resources.wsp solution package
- Web.UI – Project containing all the code for web parts, web controls, http modules and code behinds for application pages
As you see, there’s actually two projects, which are used to generate solution packages. One for the resources (stuff to goes to 12 hive) and one for the actual assemblies. This is controversy approach also in our team, but if the assemblies are separate from the resources, we can more easily and risk free, just update the actual code, without touching the xml files on disk.

For the projects, which are outputting solution packages (wsp files), we’ve configured new .targets file, which contains separate settings for Debug and Release configurations. The Target WSSSolution has been configured as the default target to these project by modifying project file.

Notice that output folder of the assemblies has been configured as “..\..\..\Binaries\Release\” in the Release configuration and that wsp package is also placed to the same folder using the above xml configuration. This is same relative path to folder what’s used by the TFS automated build process to output assemblies, before the whole folder is copied to drop location. Since the wsp package is also placed to this folder by default, it’s automatically copied to the drop location without any additional configurations. So we use the same relative path already in the development environments, so that we don’t need to change anything as part of the automated build process.

How to debug efficiently in VS2008? – This is quite common question, since in VS2008, there’s no native way debug the SharePoint customization efficiently, unless you’re using the VS extensions for WSS 3.0. Since the extensions were introduced quite late and they didn’t first support TFS integration fully, we haven’t got used to utilize them in our projects. This does not however mean that you shouldn't use them.

In our case, customers usually accept deployment of our assemblies to GAC, so don’t have to create CAS files for the deployments, which makes also the debugging little bit easier, since during development time, we can deploy our assemblies to the bin folder of the IIS application and start debugging without IIS recycles etc.

This means that we’ve setup the output folder of the Visual Studio projects to bin folder of the IIS application and configured the web application to fully trust the assemblies (<trust level="Full" originUrl="" /> in the web.config – not good practice if CAS files are used). To avoid unnecessary application pool recycles, we’ve also added additional AllowPartiallyTrustedCallers attribute to assembly, so that assemblies are loaded to IIS process memory runtime.

After these settings have been done, only thing left to do, is to attach to IIS process (w3wp.exe). To make this as efficient as possible, we use VS macro and short cut keys to establish the debug process. Basically this means that only thing we need to do to get the latest versions to development portal is to compile the code and press the shortcut in the Visual Studio. After you request the page from you browser, debugger get’s automatically attached and you can start debugging.

What kind of third party tools we use? – Actually none. Managing solution manifest and the ddf file is something which we do manually as part of the development process. Each person involved in the project has responsibility to keep the files in sync. Generally we aim to create stub versions of each control, web part and feature file in the first iterations of the project. Meaning that each feature file and template is already included in the package, even though it doesn’t do anything. Also each web part or control only write the purpose of the particular functionality – “This web part will provide the article comment functionality in later Iteration”. This way each iteration will just increase the functionalities, which are working as designed in technical architecture for customization document.

There’s lot of great third party tools available for the build process in the VS2008, but we have not decided to use them, since in the end manual updates do not take that long and if the process is automated, there’s no way to control what actually get’s packaged from VS structure. Meaning that if some features are not finalized yet for the solution package, we don’t need to add them to manifest and ddf.

How about SharePoint 2010 environment with VS2010? – When you develop SharePoint 2010 projects using Visual Studio 2010, solution package is by default compiled to the same output directories as the assemblies, so there’s no reasons for these additional configurations. Visual studio solution structure also looks quite different, since in VS2010, you’d place the code and 14 hive elements to same Visual Studio projects.

In SharePoint 2010 development, the common way to divide the files between the Visual Studio projects is based on the functionalities, not based on the file types. This means that for example the MySite functionalities are compiled to single solution package and portal and collaboration customizations to other packages. This model enables you a way to test and version the functionalities independently.

Debugging your customizations is extremely easy, since for all of the SharePoint customizations, this happens just by starting the debugging session directly from the Visual Studio IDE. Similar ways as for the 2007 environment, debugging happens in the same computer, where you develop your customizations. Target url for debugging is defined during the VS project creation or from the project properties.

How about SharePoint 2010 environment with VS2008? – This is definitely valid option and quite easy to establish (it’s only references). If you want to migrate your customizations as fast as possible to SharePoint 2010, this is most likely the temporary option you’ll use. In this case, you’ll have to modify the VS2008 project types as declared above. Since VS2010 however improve the productivity of the developers, we strongly suggest to migrate your code to VS2010.

VS2010 supports importing existing solution packages to your Visual Studio solution. This way you can relatively easily migrate your VS2008 package to VS2010. After importing, you’ll need to reconfigure the packaging model, which will require refactoring, since the Visual Studio 2010 solution structure is not total imitation from the 14 hive.

TFS side configurations

In the TFS side, all we need to do is create the build agent and the build definition for the project. This is relatively trivial process, but basically we are enabling the automated build using standard TFS side configurations. Since we’ve configured the solution package to be dropped to the same locations as the compiled assemblies (dll files either in Debug or in Release folder), we actually don’t need to do any additional steps or configure any additional msbuild settings of the build project.

TFS 2008: A basic guide to Team Build 2008

Some things to remember when you setup the build server

Ensure that you have the proper assemblies installed and/or available on the build server. Setup is dependent on the decencies on your code.
Ensure that the build service is running using domain account, which has access to the team project, so that the build service can get the latest version from the source safe
Setup share to the build server or any staging server to where the compiled builds are stored, including the solution package
Remember to setup proper cleaning process for the automated builds, since each build will consume space – this can be controlled using the retention policy of the build definition file

Depending on your code and unit testing practices, you can also add unit testing as part of your code compilation. Since some of the SharePoint dependent code can be difficult to mock, this might be difficult or require third party tools.

Automated testing environment setup

TFS automated build only verifies that the code itself compiles, but there’s still additional tasks to be done to ensure that code can be deployed and that the actual use cases work as expected. Especially for the larger projects, we’ve created additional steps, which are used to imitate the customer installation of the customizations. This way after each automated build, we have similar upgraded version of the portal, that the customer would have. To automate this, we’ve added few scripts to be executed.

The following model also decreases the inefficient working time of the tester to setup the actual testing environment, before the actual functionalities can be tested. We can certainly test some of the functionalities using automated testing, but for larger projects, it has been fairly common to have dedicated tester.

In one of our centralized hyper-v servers, we’ve setup a scheduled batch file, which is executed after the automated build process.

set Folder=\\mcstfs\contosoautobuild
set FileMask=autowspbuild_*
set VMName=contosotest02
set SnapshotName="18.10.2009 latest win updates"

set LatestFile=
for /f "delims=" %%a in ('dir /ad /b /o:d "%Folder%\%FileMask%"') do set LatestFile=%%a
if "%LatestFile%"=="" goto :eof
echo %LatestFile%

powershell -command .\startsnapshot.ps1 %VMName% %SnapshotName%
echo Sleep for 3 minutes...
ping -n 240 localhost >nul
applybuild %LatestFile% %VMName% contoso\moss_admin pwd

As you can see from the batch file content, we first solve the latest solution file, continue with snapshot modifications and as final step installs the build to the particular virtualized environment.

We use powershell to restore the status of the testing server to same status as in the production environment. This is done by using following powershell script, which restores the snapshot given as parameter to the script.

$VMname = $args[0]
$SnapshotName = $args[1]

$VMManagementService = Get-WmiObject -Namespace root\virtualization -Class Msvm_VirtualSystemManagementService
$SourceVm = Get-WmiObject -Namespace root\virtualization -Query "Select * From Msvm_ComputerSystem Where ElementName='$VMname'"

$Snapshots = Get-WmiObject -Namespace root\virtualization -Query "Associators Of {$SourceVm} Where AssocClass=Msvm_ElementSettingData ResultClass=Msvm_VirtualSystemSettingData"

#Write $Snapshots.Length

foreach($Snapshot in $Snapshots)
{
#    $Snapshot.ElementName
    if($Snapshot.ElementName -match $SnapshotName)
    {
        #Write $Snapshot.ElementName
        $TheSnapshot = $Snapshot
    }
}

Write "Applying the snapshot..."
$result = $VMManagementService.ApplyVirtualSystemSnapshot($SourceVm, $TheSnapshot)
ProcessWMIJob($result)

Write "Starting the VM..."
# Start the VM
$result = $SourceVM.RequestStateChange(2)

When this script has been executed, the virtualized environment is back online and the defined snapshot has been restored. Following step is to apply the actual build to the restored VM. For this the following script is used.

rem parameters: buildname, vmmachinename, username, password

xcopy /y /s \\mcstfs\autobuild\%1 \\contosotest02\drop\%1\

c:\pstools\psexec.exe \\%2 -u %3 -p %4 -w c:\drop\%1\release c:\windows\system32\cmd.exe /c c:\drop\%1\release\upgrade.bat http://%2 dev V12 V5

As you can see the script, we are copying the solution package from the TFS autobuild server to share located in the testing server (which was just started). After that we can execute the upgrade script on the testing server, which contains the project dependent script to upgrade the existing portal with the new version of the customizations.

By using these relatively simple scripts we now have clean and updated environment for testing every single day with all the latest customizations. Model obviously decreases the overall project costs, since we don’t need to spend time setting up the environments manually.

How to further improve the process?

After the testing environment has been setup, we can also improve even further the process. Common improvements would be to add web testing and load testing to this scenario. Due the extensive support for scripting, we can automate these to be included to the daily process. This would mean that after the testing environment has been setup, we start the automated web tests for use case validation and performance testing to ensure that new code has not dramatically decreased the performance.

Web testing is again relatively trivial task to do with the Visual Studio and it provides quick way to ensure that basic functionalities are still working as expected.

Performance testing uses the recorded web testing scripts and imitates larger load. Even though the development testing environment is not using same hardware as the production, we can do estimates and assumptions based on baseline tests.

Baseline testing means that we have made tests in the customer environment and in testing environment using same customizations. If the new version is decreasing test environment performance for 20%, we can assume that the result would be most likely the same in the production.

Improvements in SharePoint 2010 for the process

As mentioned already earlier in this post, when you develop customizations for the SharePoint 2010 with Visual Studio 2010, there’s native support to compile solution packages to the output folder of the Visual Studio project, so there’s no need for any msbuild script changes.

Other huge improvement is the native support for upgrade and versioning in the feature framework side. This will help to upgrade already existing portals and manage the versioning of the customizations. Traditionally in SharePoint 2007, this has been done with custom feature receivers, which modify the existing content. In SharePoint 2010, we have much more powerful tools to manage the portal lifecycle and to update the already existing content. Also the logging mechanism have been dramatically improved to help with customization troubleshooting, if deployments fails or something unexpected will happen.

We’ll release lot of new information concerning the SharePoint 2010 development in upcoming months, so stay tuned.

Summary

Setting up the standardized development process might seem like a large task, but when the environments and processes have been defined, it saves lot of resources to actual efficient project work. The processes we use for our enterprise projects (30-500-xxxx man day projects), is constantly evolving process, which is improved and changed based on the experiences from the projects.

Following people have also contributed to our standardized process: Jaakko Haakana, Juhani Lith, Janne Mattila, Tom Wik and Jukka Ylimutka.

Hopefully this was useful.

SharePoint 2010 – More public information available

2009-10-21T08:09:56Z

Finally SharePoint 2010 information is publicly available after the release on SharePoint Conference past Monday. Since people participating to early adopters programs and for example MVPs, have had a change to work with the early builds for a while, there will be lot of new information available in the blogs during upcoming weeks.

Below is small collection of the most interesting blog posts and sites currently available.

Few links concerning the features available

Microsoft Office SharePoint Server 2010 Virtual Pressroom
- Lot of interesting videos and other content
SharePoint 2010 introduction from Jeff Teper
SharePoint Conference Keynotes – from Arpan Shah’s blog
SharePoint 2010 informational site
Improvements to the Core SharePoint Platform & How the Benefit SharePoint 2010 Web Content Management – Andrew Connell

Miscellaneous blog posts and articles

SharePoint 2010 Developer Center
- Introduction from SharePoint developer Documentation team blog
Online SDK
SharePoint 2010 in TechNet
Visual Studio 2010 Tools for SharePoint Development – MSDN magazine – Steve Fox
SharePoint 2010: Developer Tools Overview – harbar.net
SharePoint 2010 Developer Dashboard – Bob Fox
Single Server Complete Install of SharePoint 2010 using local accounts – Neil Hodgkinson
SharePoint 2010 documentation and posters

As defined at the SharePoint team blog, public Beta available in November and during this time, you can start developing functionalities using Visual Studio 2010 Beta 2, which will contain all the necessary project types to support natively SharePoint 2010 development.

“Can I use Visual Studio 2010 project types for MOSS 2007 development?” – this has been fairly common question during the early training sessions. Theoretically it can be possible, if you update the references, but it’s not recommended. Natively VS2010 SharePoint tools supports SharePoint 2010 development

WCM enabled collaboration sites

2009-02-01T23:55:28Z

Usually collaboration sites (team sites) and WCM functionalities (publishing sites) are seen as two totally separate functionalities provided by SharePoint. However by combining these both options, we can provide even more sophisticated functionalities.

One of the challenges in the team sites is the fact that there’s no easy way to store metadata in “site level”, since all of the stored information is managed in the lists. Wouldn’t it be nice, if we could dynamically list for example all of the team or project sites of one particular company division or group team sites based on the project manager assigned to the particular project site.

Usually this kind of requirements are solved by implementing a custom web part, which is used to store the “site level metadata” to database. This is good solution, but actually we can implement the same functionality just by utilizing out of the box functionalities.

Combining best of the both

WCM provides us a way to store “site level” metadata. This can achieved by storing metadata information in the welcome page
- This way we can utilize for example CQWP to list the content dynamically within site collections
From team sites we can combine the great collaboration tools, which usually are not provided in WCM sites

Following chapters define one example usage model, which I prepared for development oriented trainings back in spring 2007. We have also used this same model successfully in multiple customer engagements.

Introduction to the solution

Following project catalog and project site functionalities are part of the more complex development methods solution, which demonstrates different possibilities of the SharePoint. Branding of the site has been done in matter of hours, so so don’t concentrate on the actual look and feel, rather to the functionalities. I didn’t want to spend too much time with CSS.

Project site

Requirement– Customer needs project sites, which should store also site level metadata. This information is used to aggregate site information in multiple places on the Intranet. Project manager, as the site owner, should be able to manipulate the site metadata to indicate progress of possible issues in the project.

Requirement– Customer wants to have project phases as the document libraries in the project site. These document libraries have different document templates.

Following steps defines the different features and functionalities developed to be able to provide the requested functionality.

1. Create a necessary site columns, which will be used to store the site specific metadata. Let’s create a feature, which defines the necessary site columns based on the requirements. Below is example of single site column required to store the organization division information.

2. Create a content type used for the welcome page of the project site. Since we are creating a publishing page content type, the content type is inherited from the out of the box Page content type and the document template is set as a specific aspx page.

3. Create necessary document content types used in the project site. Notice that we use the _cts –folder in the target definitions of the template upload (module element). Underneath this folder there will be specific content type folder created, when ever a new content type is provisioned to the site collection. This is good place to store the document templates, unless the templates are frequently updated (another story, another time…).

4. Create document libraries used in the project site, from where the document content types are provided. In the below image, we introduce a new document library template and create a new instance from it to be used to store documents in the Execute phase of the project. “Why new list template?” – If we only bind the document content types to default document library, the out of the box document template would be still available.

5. Bind the content types to the specific libraries. In the following image, we bind the specific document content types to the execute phase library. “Why aren’t we binding the content types directly in list template schema?” – this approach allows use to use the same document library template for multiple different instances and just bind the specific document templates depending on the instance.

6. Let’s not forget to bind the project welcome page content type to the pages library, so that the necessary fields will be provisioned to the list.

7. Now when the project site welcome page content type is available in the pages library, we can provision initial values for the site created. This can be done by setting the default.aspx page’s metadata appropriately as in the image below. Notice that we the the ContentType value as the content type declared earlier in the feature. We also define the initial status values to be “Green”.

8. We need to create a page layout, which is responsible of rendering the metadata information for the end users (I wont’ declared the detail steps to save some space). Now we can create the site definition used to provision the site. When the site is provisioned, we can see the initial values defined in the module above. “Why a custom site definition?” - If customer would like to utilize the oob team sites and other templates as they are, but they would also like to have this new definition available, custom definition is the only way to go. Since the WCM features are enabled, the site template option is not supported.

9. Site specific metadata can now be managed directly within the welcome page as long as the fields are rendered correctly in edit mode.

10. One advantage of this approach is also the possibility to utilize the field controls for content editing. This improves the content editing experience.

11. When the values have been updated and information is published, we have standardized site model for all of the project sites. This way the end users of the portal can easily see the key information of the specific project from the standardized place in the layout.

12. As part of the requirements we also created document libraries for each project phase and used content type binding to associate the specific document content types to the specific libraries. As an outcome we are providing different document templates from different document libraries. This way we make the document creation process more efficient and save time for the site end users.

Project catalog site

Requirement – Customer wants to list dynamically all of the project sites created underneath the particular catalog site. Aggregation should list the sites based on the organization division and the phase of the project. Only those sites on which the specific user has access to should be shown.

Solution is to use Content By Query Web parts (CQWP) as part of the site provisioning process and set the web part configuration values appropriately. Since the organization division and the project phase are stored as the metadata of the project site welcome page (created with specific content type), we can simply utilize the standard out of the box functionalities.

Now since we are using CQWP to aggregate the information, all the updates are automatically updated to the lists. Out of the box Site Directory does provide similar functionalities, but the list is not dynamically updated and the information is not stored in the specific site, so that the site owner (for example project manager) could not update the information.

Requirement– Only project sites should be created underneath the project catalog site.

Define the publishing features appropriately, so that only the project site is visible in the Create Site functionality.

Requirement– Customer wants indicate possible issues in the project sites for the managers based on the status updated by the project manager.

Luckily we had three status indications stored to the the metadata of the sites, which we can utilize. Let’s also create a audience for the managers and show the web part only to those persons, whoe belongs to it. Below is the picture to show dynamically those sites, which have any of the status metadata values selected as “red”.

Putting it all together

Of course all of the functionalities are packaged to the solution package (wsp-file), which can be used to reproduce the functionalities in any MOSS deployment. This means that we need to create the manifest file, which is used to explain the SharePoint the content of the customizations, as in what features, site definitions, assemblies, web parts etc are included in the solution.

As addition to the manifest file, we need to create the ddf-file which is used when the functionalities are packaged to the solution package.

After this, we can deploy the same functionalities to any MOSS deployment and we can be sure that it works identically as in the development environment.

Independent site collections

Example design declared in this article works when the project sites are created to same site collection as the project catalog site. This has both advantages and disadvantages. One common design is the have the individual team sites created as own site collection. Also in this case, the WCM features enhance the functionality. If the site metadata information would be stored to external database, we’d have to create custom search functionality.

Since the “site metadata” is stored to welcome page based on content type, we can create managed properties of the information stored. Managed properties can then be directly utilized in the search results and we can provide same user experience as in example declared in this article.

Possible enhancements

There are multiple different ways to improve the defined functionality. Here’s few simple ideas.

1. Site approval – since we are utilizing the WCM functionalities, we could easily attach site approval process before the site would be visible for other portal users. By using minor versioning in the pages library, the site would not be visible for other persons than the site owners before the site is published as a major version. For the publishing process, we can specify any kind of workflow.

2. PKI values for the status - To indicate the project status more efficiently, we could create a custom field control, which renders the status values using traffic lights in the project site. For the catalog site, this is even more easier, since we can do conditional rendering in the xslt used by the CQWP. This way we could extremely easily create a list of all projects in organization and indicate their status using traffic light model.

WCM functionalities provides us numerous different functionalities, so you can easily invent more possibilities.

Considerations

“Why would I create standard team sites, rather than WCM enabled collaboration sites?” – good question. If the requirements can be met with more simplified solution, like feature stapling to out of the box team sites, than there’s no reason to enable WCM in team sites. If you need to provide more enhanced functionalities, enabling the WCM functionalities might just be the solution you are looking for.

“I use database to store the metadata values of the site, is this bad solution?” - No, but remember to consider he overall consequences of your architecture choice. The solution to choose always depends on the requirements and functionalities to be provided. The downside of the database based model is however the fact that the metadata is not stored within the site and therefore we need to do additional work to ensure that the values are in sync. Also the database based model requires additional work on the operational point of view in sense of disaster recovery and maintenance. The WCM based model keeps the metadata in the site and even though the site location in the hierarchy would be changed, the metadata would be intact, since it’s stored as part of the site.

Hopefully this was useful.

Internet facing MOSS sites without content deployment

2009-01-30T00:03:17Z

Lately there has been quite a lot of discussions concerning Internet facing MOSS sites and content deployment. Quite often there’s misconception that MOSS cannot be used as Internet facing platform without separate authoring farm and utilizing content deployment. Assumption is understandable, but completely wrong.

By utilizing possibility to have multiple zones for single SharePoint application, we can setup an environment, which is can be accessed by both anonymous users from Internet and content editors from corporate network using windows authentication.

Conceptual model

Zone in the SharePoint basically means different access points to access the same content. Each of these access points can have their individual configuration for the network and for the authentication. When we create a new zone, we actually create new IIS application, which is pointing to the same SharePoint application.

This model is often used in extranet scenarios, where the external users are authenticated using forms based authentication (FBA) and internal users are authenticated using windows authentication (NTLM). Same model can of course be used to provide content editing functionality for Internet facing site.

Following picture defines the elements more detailed.

#	Element
1	External users are seeing only the www.[sitename].com address. This is physically one IIS application, which accesses the MOSS application. Anonymous access is configured to the zone and the ViewFormPagesLockDown feature is activated for site collection to enhance security.
2	Internal users will have access to http://internet , which is exposed only to the internal network. This secondary IIS application is used for creating the content in windows authentication mode to same MOSS application
3	Actual SharePoint application is in the database and both zones access the same content.

Infrastructure architecture

Following picture defines the model in infrastructure level. There are multiple different variations of this kind of setup depending on the network policies and possibilities. Each of the elements and few possibilities are declared also in detail.

#	Element
1	Internet facing network zone for external people to access the service. Anonymous zone(s) are accessed from this direction.
2	Internet facing firewall and network load balancer, which permits only necessary ports to be used when accessing the portal.
3	Web front end servers actually serving the content for the external url, which is configured to the NLB and to the alternate access mapping. Depending on the networks and the security setup, these can actually also be in the corporate network. Since all of the zones created to the MOSS applications are synchronized between the servers, the IIS application for NTLM zone exists in these servers, but there’s no way to external people access this IIS application.
4	Optional firewall depending on the network, if the web front ends are in DMZ zone and the farm is divided between network segments. This is so called split-back-to-back farm.
5	Optional internal servers, which can be used to access the internal zone configured to use Windows authentication. Zone is only available for corporate network using internal DNS entries. Depending on the requirements and network, the NTLM zone could actually also exists in the WFE servers as declared partly already in step 3. This is not usually seen as a valid option, but actually the model is justified with security considerations and with cost saving since we would not need separate authoring farm.
6	Internal access point to the portal using NTLM. From here the content editors can access the portal and make necessary changes.
7	Database cluster for the MOSS farm.
8	Index server crawling the sites. Depending on the content and load, the index server can actually also be acting as the WFE server and there for it can access the content directly from itself, rather than causing load to the other WFE servers. There are however multiple different options on this one, so it’s a different discussion.

Considerations

Customization development and deployment

When separate staging or authoring farm is used, there’s more detailed processes to follow to keep the farms in sync, so that the content publishing work properly. In this option, there’s only one farm, so the deployment practices are more simplified (separate QA farm of course though recommended).

Other advance on the single farm setup is more simplified possibilities for custom solutions. Let’s have an example concerning simple feedback functionality.

Objective – Collect feedback from end users by providing a simple form for information entry. Store the sent feedback to secure list in SharePoint, which can only access the web masters.
Single farm with Zones – Create feedback list to the root web and setup the access control appropriately to it. Use elevated privileges in the custom form to write the feedback to the list. Web masters can access the list directly using the NTLM zone.
Separate authoring farm – Since the content in the internet facing farm should not be updated for proper content publishing to work, we need to implement the write back to the authoring farm using web services. Writing entries for single list is natively supported, but especially little bit more complicated solutions increase the costs of the customizations.

Management

Since there’s only one farm to manage and monitor, the overall costs of the MOSS deployment are considerable smaller than having two farms. Also keeping the separate farms in sync is more complex than having single farm to configure. Model also decreases the storage requirements, since there’s no duplications concerning the databases of the individual MOSS farms.

Security

All the concepts declared in this article are dependent on the network configurations and security settings. Especially when we are exposing the services to the Internet, we really need to ensure that the network and farm is properly configured.

Also all the customizations developed have to follow the security recommendations so that any sensitive information is not exposed.

Content editing

Since publishing of the content is instant when the Publish –button is clicked, the content can be easily modified and managed. There’s no delays of getting the information released to the internet, except the possible caching configurations.

It’s of course important to notice the model in prepared training mater, like instructing the content editors to use relative addresses for resources, like images and for the links within the portal.

Real life experiences

We have used this model in multiple Internet facing sites during past few years successfully. Administrators have been pleased on the fact that there’s only one farm to manage and monitor, content editors have been pleased on the simplified model of authoring the content and generally customer directors have been pleased on the fact that the model saves investments done to hardware and to the possible customization.

Hopefully this provides more insight on the flexibility of the SharePoint and for the different possibilities it provides. Each enterprise architecture is independent and they all have their own environmental characters. Therefore the guidance provided from TechNet or from numerous blogs should be always adapt to specific engagement.

Office 14 for Web

2008-10-31T10:20:46Z

This was so cool video, that I had to publish the link. Pretty interesting functionalities are coming up.

http://channel9.msdn.com/posts/PDCNews/First-Look-Office-14-for-Web/

Caribbean English and SharePoint - localization techniques for WCM sites

2008-10-23T16:20:39Z

This was so interesting, that I had to share it more widely... I'm working with one global customer concerning Internet facing MOSS site, which will eventually have more than 50 local sites within their own languages (including the corporate sites in multiple languages). Translation of the labels used in the sites are based on standard RESX handling, without any custom resource providers.

So basically as part of the solution deployment, the resx files are distributed to app_GlobalResources folder of IIS application in each WFE (requires some extra effort to be automated during deployment, but that's a separate story). The RESX files are not included in to the assemblies to provide more flexible way of updating just the translations without any other changes.

As part of the following releases, there was a requirement to generate the translations for the Caribbean English. You might wonder the business case, but there are certain phrases, which should be translated differently as for the US... similar way as there's different translations for UK. For initial testing, the RESX file with the correct culture information (en-CB) was created. When the file was introduced to the application, whole application came down with following error message.

Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0101: The namespace 'Resources' already contains a definition for 'CUSTOMER'

Well... that's interesting, since based on the .NET 2.0 documentation, the en-CB is officially supported locale. I did little bit more digging on the case and found out that there's actually a KB article released concerning issues with few locale codes, if certain security fix has been installed. KB article defines that for example in this case, the locale should be actually en-029. After changing the RESX file name correctly, everything started working again and translations were successful.

Improving the translation logic

Obviously the situation declared above was extremely scary. You can pull down the whole farm just by providing wrongly named RESX files. That's not good at all. Actually there's similar implications when the RESX file contains duplicate keys etc. It's of course clear mistake in the RESX, but the fact that the farm will be dropped to it's knees, is simply extremely scary. In our case, we luckily had strict process of getting the new files published in the farm (similar as declared here), so this didn't cause any catastrophic issues to production.

What can you do? - ASP.net provider model to rescue... since we can extend or change the default asp.net functionalities, we can write our own resource provider to manage the different translations. Of course the requirement of having custom provider to be written depends on the requirements for the project - especially on the high availability sense. Depending on the requirements and implementation, you can also define your own logic concerning fall back mechanisms and duplicate keys etc. etc. etc. More information on the resource provider can be found from the following MSDN article.

MSDN - Extending the ASP.NET 2.0 Resource-Provider Model

This approach also provides more flexible ways to provide the translations. By creating a custom resource provider, we could also fairly easily provide UI to update the translations directly for example from the site settings page of the particular country sites. This way the maintenance of the labels can be more easily delegated and managed by the web masters of the particular country sites.

Hopefully this was useful.

Project planning and application lifecycle management

2008-09-16T21:00:01Z

One of the most important and often overlooked thing to cover in planning phase of the projects is the application lifecycle management (ALM) for upcoming portal. In this context I don't mean just the lifecycle management for the customizations, rather for the full process and environments. Every single project done with SharePoint technologies (WSS/MOSS), should define the clear rules and practices to manage the process as early as possible.

By setting the ground rules immediately in the planning phase of the project, you can take them into account during the technical planning of the deployment and of course also in the operational planning. Following image and table defines one example process, which follows the continuous integration model for SharePoint development (Continuous integration in MOSS development using TFS).

Following table defines the steps and phases one-by-one.

#	Phase / Element
1	Developers develop individual features and functionalities based on of the technical specification using their independent virtualized environments, which have access to the TFS server for work items, source control etc. Virtualized environment have to be in-sync with the production environment concerning the licensing and patching. Customizations developed with enterprise license; don't necessarily work in standard environment. Patches and service packs should be also keep in sync. Ensure that it's somebody’s responsibility to keep the virtualized environment up to date.
2	TFS Server used to store source code and other project related information. Developers can also sync their environment using the artifacts stored in TFS. It's obvious, that developers have to have ensured connection to the source control repository.
3	SQL Server instance of the TFS, used for actual storage of the different artifacts and document. Ensure that this database is fully managed, monitored and operational; otherwise the development cannot be conducted.
4	Development integration server, which is used to verify the builds from the TFS, preferable using automated build process. Server should be kept in sync with the production environment. Integration server is used for integration and deployment testing. Also the initial functional testing for full package should be conducted in this environment.
5	Project members (for example project manager, testers and even customers representatives in some cases) can follow the progress of the project and give feedback based on the builds deployed. Define the ground rules for accepting the deployments to quality assurance environment from the integration environment. If the development happens in ISV premises, this server is most likely located also there. It's not however good practice to have similar server in these cases also at the customer premises, so that it can be used to deploy pilot or draft versions of the solution. This way we can establish communication channels concerning the upcoming features as soon as there's something to deploy. This approach minimizes surprises at the end of the project and the customer representatives can use the environment for training purposes as early as possible There has to be clear rules to follow for accepting the deployment for following phases.
6	Quality assurance environment used for functionality testing and acceptance testing. In ideal world this environment is identical as the production environment, so that it can also be used for load testing. Quite often though, the environment is virtualized for more convenient maintenance. Load testing can be nevertheless conducted also in virtualized environment, if project performs the initial load testing (base line testing) during the first version of the portal. This way the future load testing results can be compared to these base testing values. In sense of licensing and configuration, the environment should be completely identical to production. This ensures that if the deployment is successful in this environment, it will work also in production.
7	SQL Server of the quality assurance environment. Obviously the configuration should be identical as for the production. Operational setup should also follow the production, so that full portal behavior can be observed also in this environment.
8	MOSS environment used for production purposes. There should be clear responsibilities and operational guidance for this environment to ensure that possible issues caused for example customizations can be solved in timely fashion. One of the key things to document and to follow is the version handling model of the customizations (how things are updated). As written earlier, there has to be crystal clear model for deployment of new versions and guidance to follow in case of any issues encountered.
9	SQL Server for the production, which is fully managed and monitored 24/7. In case of any issues, there should be clear guidance on how to proceed. Backup and restore process should be verified in quality assurance environment and if possible also in production environment, before going live with the portal.

Considerations

Following chapters defines few points to consider when the full process is planned. I also want to raise few pointers, which I have personally run into in multiple partners and customers.

Are the code and SharePoint artifacts in safe place?

It should be clear that the all of the customizations developed for SharePoint portal are stored in some source control system, like Team Foundation Server. You don't want be in situation where the customization are gone, due failure in single laptop or desktop. Also consider and ensure that the source control system is in safe hands. If there's critical issues in the production, which requires instant code level fix to be deployed, you need to ensure that the source control is up and running.

Basically this means that the source control system should be high available or at least there's a backup plan to access the source code in timely fashion, so for example possible SLA's can be achieved.

Is the process high available?

We need to go through the steps in the process to ensure that there's no single point of failure in the process. Technical failures can be fairly easily identified, but we also need to consider the steps, which require human intervention. You don't want to be dependent from single persons, which could compromise the environment for example during summer vacation. There needs to be a back up person for each critical responsibility, with sufficient knowledge concerning the possible tasks to be done.

Is there clear model to update the customizations?

Setting up the initial version of the portal is quite straight forward, but the possible updated versions have to be carefully designed. It's quite common that after the initial version, there will be additional functionalities included in the portal. At some customers, there are quarterly releases, which enhance the functionalities provided for the end users by introducing new possibilities and options. If the upgrading model is not clear before the initial customizations are deployed, life can get complicated. Can we use the in-place upgrade of the solution packages? Does the end users use SharePoint designer in production? Every decision has it's effect and there for we need to ensure the model already in the planning phase.

Personally I've seen way too many SharePoint deployments, which have been build up nicely, but when we need to update any of the customizations, the life get's over complicated.

Is the customization deployment model scalable?

The usage of the solution package in deployment of the customizations can be considered as the de-facto way of deploying ANY customizations to the portal. By using solution packages we can ensure that in case of increased load for the MOSS farm, we can scale the farm out, by adding additional servers. If the deployments are done manually, there's too huge risk for human errors and the servers won't be in-sync. Manual deployment would require also huge amounts of additional actions to be conducted when the new server is introduced to the farm.

Summary

I listed only few pointers to give you an idea of the things to cover in you project. Of course model and required processes is fully dependent on the scale of the deployment. If you only use closely out of the box SharePoint installations and the modifications are done using SharePoint Designer, you don't necessarily have to think through these kinds of things. For large scale projects, the models and processes have to be planned carefully. It's not rocket science and you should not over think the processes, but by planning a head, you can ensure the long running service, which will be definitely worth of investment.

MCM for SharePoint

2008-08-01T10:12:05Z

Have you already completed the four MCTS certifications available for SharePoint and would like to have more challenges?

Would you like to distinct yourself as the real subject matter expert for SharePoint? Check the following links for more information concerning the upcoming Microsoft Certified Master (MCM) for SharePoint.

Office SharePoint Server 2007 TechNet content released as .chm file

2008-08-01T09:34:20Z

I just noticed that the SharePoint IT pro documentation team has released Office SharePoint Server 2007 TechNet content as a downloadable file, to be able to access the content also off-line (intercontinental flights etc.). According the announcement, the package will be updated in monthly. This is also good reference guidance, if you are in customer premises and want to verify something without access to the actual site.

Blog entry - You asked for it, you got it: .chm builds of library content
Download - Office SharePoint Server 2007 Technical Library in Compiled Help format

Continuous integration in MOSS development using TFS

2008-07-29T19:58:09Z

I've been delivering quite a few technical training's during past year and one of the most discussed thing is the setup of the development environments for large scale projects. Especially large ISV's are really interested on the the practicalities of utilizing the TFS as the continuous integration (CI) and/or application lifecycle management (ALM) platform. For standard .net projects this has been the way to manage large projects and it's obvious that the investment and practices are wanted to be utilized also for the SharePoint based development.

Since SharePoint development differs quite a lot from the standard asp.net development, this has not been that straight forward. Following scenario is example done using Visual Studio and TFS, but the principles and practices can be easily adapted also for other continuous integration solutions, like the CruiseControl.NET (CCNet).

Setting up the Visual Studio solution for the TFS

Before the continuous integration can be setup in the TFS side, we need to configure the Visual Studio project correctly, so that when ever build is initialized, newly compiled solution package (.wsp) is created. There are numerous blog entries available from the Internet including the detailed steps for this.

MSDN - Automating Solution Package Creation for Windows SharePoint Services by Using MSBuild

Basically the idea is to configure the Visual Studio solution such away that each assembly is first compiled and then the solution package is compiled using the MakeCab.exe. For the VS solution where you have multiple projects, make sure that you have defined the project dependencies such away that that the actual solution package project (the one which output is the wsp file) is dependent on the assembly projects (outputs dll's). This ensures that the assembly projects are compiled, before the wsp package is generated.

Creating the auto build project for TFS

When the auto build process of the TFS has finalized by compiling the Visual Studio solution, we have received fully package solution package(s), which are ready to be deployed to any SharePoint server. Since the TFS is not aware of these kind of file types, it does not by default copy the wsp package to the drop location. This is not an issue, since we can modify little bit the build project to be able to initiate the portal recreation. By opening the build project file (by default TFSBuild.proj located in the TeamBuildType/[build name]/ folder in TFS source control) and adding following xml elements, we make sure that the wsp package is also copied to the drop location and additional batch file (this case the rebuild.bat) is executed.


<Target Name="AfterCompile">
  <Copy SourceFiles="$(SolutionRoot)\[TFSProjectName]\[ProjectName]
                    \SolutionFiles\Package\[SolutionPackageName].wsp" 
        DestinationFolder="$(DropLocation)" />
  <Exec Command="C:\TFS\rebuild.bat" 
        WorkingDirectory="$(DropLocation)" />
</Target>

Note. Above example of using rebuild.bat is dependent on the fact that the SharePoint is located in the same server as where the build happens, which in most of the time, is not the case. Alternative solution is declared in the following chapter.

Really nice feature concerning the auto build is also the fact that operations and actions logged by the MakeCab are automatically included in the TFS auto build report, which is generated for each executed auto build. If there's anything wrong with your solution files (manifest, ddf etc.), the errors will be automatically logged here. Each executed build has it's own detailed information, from where you can access the build log as we can see from the following image.

Build log (BuildLog.txt) has huge amounts of details concerning the actions taken in particular build. All the MakeCab logged information is also included in the log for detailed analyses on the SharePoint solution package compilation.

Adding rebuild of the portal to scenario

When the wsp package has been created, it has to be of course deployed to the portal first, before it can be tested. This can accomplished manually, but it can also be automated, so that the portal is recreated automatically as part of the auto build process.

Personally I have done this few different ways. Initially I created a console application, which was executed as a scheduled task by the Windows OS. More convenient way to do the same would be to create few new extensions to the stsadm, which are responsible of setting up the environment, so that project members can access the latest version without any manual intervention. If the build server and SharePoint server are different servers (most likely the case), you can schedule the execution of the stsadm commands to batch file located in the server of the drop location.

Following defines one approach used. The tasks are dependent on the type of development and can be customized based on your requirements.

Objectives

Redeploy the new solution package to the farm - remove any previous versions, if exists
Recreate the portal hierarchy using portal site definitions
Define access to the newly created hierarchy for the project managers and testers

For these objectives, I created following stsadm extensions, which are sequentially processed. These commands access the farm using object model. By default the stsadm provides already similar functionalities, but by creating my own commands, I can easily improve and/or add any actions to be deployed as part of the auto build process.

Command	Description
deploysolutionadv	Responsible of deploying the new solution package to the farm. Retracts and removes any previous versions from the farm, if exits. Command is used to redeploy the solution package as part of the daily builds.
recreatesitecollection	Command recreates site collection using specific template defined as parameter. If site collection already exists in the farm, it's deleted. Command is used to recreate the site collection for the daily builds. Portal site definitions are great way of providing immediately full hierarchies for the newly created site collection.
assignuserstogroup	Grant access to defined site collection for the users defined as parameter. Command is used to define access to the newly created site for the persons responsible of verification tasks.

Full scenario for continuous integration

Following image defines the key steps for the continuous integration within the SharePoint development. This model can be considered as the development time process for the project.

Following table defines the steps and phases one-by-one.

#	Phase / Element
1	Developers develop individual features and functionalities based on module plan (part of the technical specification) using their independent virtualized environments, which have access to the TFS server for work items, source control etc.
2	TFS Server used to store source code and other project related information. TFS is scheduled to build the integrated version of the package using build automation functionalities. Developers can also sync their environment using the artifacts stored in TFS.
3	Development integration server, which is used to setup the outputs from the TFS. If required, this server environment can be utilized by multiple projects as long as they have separate application on which the solution is automatically deployed (often the case in ISV environments).
4	Project members (for example project manager, testers and even customers representatives in some cases) can follow the progress of the project and give feedback based on the builds deployed. By providing instance access to daily builds, project will get instant feedback for the developed functionalities Daily builds provide flexibility to follow the progress and to discover any required changes in the design as early as possible

Possibilities to test and verify the provided functionalities in the development integration server depend heavily on the type of the solution to build. In case declared above, complete custom site definitions with initial configuration of custom web parts are included and there for when the portal site definition is used to create the structures, new functionalities are directly visible in the portal.

On the other hand, it's quite common that you are developing functionalities, which are associated to the out-of-the-box site definitions using site stapling techniques. In these kind of projects, the new functionalities would be available, as long as you create the definitions, on which the stapling has been added.

Even though you would be developing only few custom web parts, by utilizing the deployment model as declared above, you could verify the deployment packages for your project and test the web parts in the environment. If you are only adding few new web parts to out-of-the-box portal, you might want to consider automated activation of your custom features, which deploys the .webpart files to the portal. This way the tester(s) could verify the functionalities by adding new web parts to the portal using standard web part picker.

SharePoint artifact development

One of the thing to consider when setting up the project is the storage location of the SharePoint artifacts. Even though SharePoint provides version control for artifacts it stores, it cannot be considered as a actual source control system. Especially if the development is done by ISV, which is the most common case, it's good to have the source code including the artifacts in sync in the source code system (like TFS) to be able to label the actual releases of the developed features. Consider the practicalities to update your customizations from version 1.0 to 2.0 (I'll write later practices for version handling of your SharePoint project).

Artifact development on the ISV side can of course utilize the standard SharePoint tools, like SharePoint Designer, which increase the productivity during the initial creation of the functionalities. There's however no easily way to sync the artifacts from SharePoint to the Visual Studio package responsible of the encapsulating the solution packages. Whenever the development for particular artifact is finalized, it can be however copied to the package manually. This way for example the master page developer, can first finalize and verify the functionalities in her/his own virtualized environment and provide versions to the official solution package when appropriate.

Real life experiences

I initially created this process and the necessary configurations for one enterprise project, which started July 2007, where I was acting as the technical lead for the infrastructure architecture and for the customized development (at the time project started developers from ISV didn't have that much experience on the customization models). Overall amount of developers in the project was up to seven persons and since the development happened at customer premises, the daily builds provided easy way for the customer representatives to follow the progress and give instant feedback whenever required.

Similar setup would be however extremely useful for also any ISV, which does SharePoint development. Since the recommended deployment method for any customizations in the SharePoint landscape is to use solution packages, this process would be useful to any development project, no matter the amount of the customizations (from one web part to enterprise projects with tens of developers).

One additional advantages from automation came as a surprise during the project - or initially it was not foreseen. One of the guidelines we kept in the project was to utilize immediately fresh copy of the virtualized environments, if unexplained errors were encountered during development, that could not be solved in timely fashion. By utilizing the same process as for the auto build, we could recreate the full portal for the development environment from scratch (huge WCM portal) just by running the predefined batch files. This decreased the time required for setting up the development environments with latest build and there for saved project resources for actual activities to be completed.

Summary & more information

Utilization of continuous integration practices within the SharePoint development projects provides fairly easy way to increase the quality of the delivered functionalities. The process might first seem difficult, but when the initial configurations and actions have been completed, process can be reproduced easily to any number of projects.

Links to the concepts defined in this blog post

I'll write more guidelines concerning the ALM (Application Lifecycle Management) and other project practices for SharePoint development in upcoming posts.

Define Central Administration database to use in MOSS installation

2008-04-24T13:56:15Z

By default when you install new MOSS/WSS farm to your environment, the content database for Central Administration application is renamed automatically using standard prefix (SharePoint_AdminContent_) and randomly generated GUID to avoid any problems if there's multiple MOSS farms installed using the same SQL Server.

If there's only one MOSS farm installed using the same SQL Server, you can quite easily identity the content database for the Central Administration web application, but especially if you have multiple MOSS farms utilizing the same SQL Server cluster, you might have difficulties to identity for example the Internet MOSS farm admin database, if the extranet farm is installed on the same server.

Usually also the companies hosting the databases would like to know the exact name of all the databases created as part of the installation process before hand, so that they can establish the necessary operational activities (backups etc.).

Solution for the naming issue is quite simple, but it has to be done before the actual MOSS farm installation is finalized, meaning before the actual MOSS farm databases are created using configuration wizard. After running the setup.exe, close the configuration wizard and move to the folder where the psconfig tool exists. This is the same folder where stsadm tool is located and by default the path is c:\program files\common files\microsoft shared\web server extensions\12\bin.

Execute the following from the command line (change the values to the correct ones to use in your environment...especially the farm account details)

psconfig -cmd configdb -create -server servername -database MOSS_Config -user domain\farmaccount -password accountpwd -admincontentdatabase MOSS_Content_Admin

Note. Make sure that the account you are using has the sufficient access rights to the database server as declared in Technet.

When the configuration is ended, the configuration database (this case the MOSS_Config) has been created to SQL Server (in this case to server servername) and you can restart the configuration wizard. From the wizard you can notice that the initial values have been already set and the server has already been attached to the newly created MOSS farm.

At this stage you can do the traditional next-next-next installation, since all the required information already has been configured. When the configuration is completed, the admin database you defined in the psconfig command has been created to the SQL Server and the Central Administration is automatically started.

Interesting governance and training material for SharePoint

2008-04-11T09:22:48Z

I'm currently working in two large MOSS project (Global Intranet & Internet facing site) where there are requirements to define the governance models and organize training for the end users. It's quote common that companies do not realize the requirements in this area in time and when the projects are already in finalization phase, this causes huge fuzz... Even though the issue was raised immediately when the projects start... well nevertheless... Here's few extremely important links to material which are useful for every single MOSS project out there.

I'm not anymore even counting the times on when the customer have been amazed that Microsoft is providing this kind of guidance and training material... Yes... we actually do also something else rather than only install the products / servers... especially with MOSS.

Governance and general guidance

SharePoint Gear Up
- http://sharepoint.microsoft.com/gearup
- Huge amount of good materials concerning how to plan the overall project based on the SharePoint technologies.
SharePoint Governance site at Technet
- http://technet.microsoft.com/en-us/office/sharepointserver/bb507202.aspx
- Excellent site including numerous links to relevant documents, guidance and information
SharePoint Governance Checklist Guide
- http://technet.microsoft.com/en-us/library/cc261826.aspx
- Excellent checklist, which points what to be plan and decide as part of the governance planning
SharePoint Governance and Manageability (Codeplex)
- http://www.codeplex.com/governance
- Code examples and tools to manage sites more easily
Example governance plan
- http://go.microsoft.com/fwlink/?LinkID=92333&clcid=0x409
- Sample by Mark Wagner and Joel Oleson

Training material

Following downloads were also extremely interesting, especially the Training Portal Edition, since it can be customized based on the customer case. In large global projects it's extremely important to provide consistent and well planned training materials for the administrators and end users... especially if they don't have necessarily any previous experience on the SharePoint.

Microsoft Office SharePoint Server 2007 Training Standalone Edition

http://www.microsoft.com/downloads/details.aspx?FamilyId=7BB3A2A3-6A9F-49F4-84E8-FF3FB71046DF&displaylang=en

Step-by-step through beginning to advanced features, including Collaboration, Business Processes and Forms, Portals and Personalization, Search, Business Intelligence and Enterprise Content Management.
Includes videos, interactive tutorials, and articles.
Accessed through your browser after you install the application on your personal computer.

Microsoft Office SharePoint Server 2007 Training Portal Edition

http://www.microsoft.com/downloads/details.aspx?FamilyId=673DC932-626A-4E59-9DCA-16D685600A51&displaylang=en

Built on the Microsoft SharePoint Learning Kit,
Designed for server administrators who want to help their end-users learn how to use the features of Microsoft Office SharePoint Server 2007.
Step-by-step through beginning to advanced features, including Collaboration, Business Processes and Forms, Portals and Personalization, Search, Business Intelligence and Enterprise Content Management.
Includes videos, interactive tutorials, and articles.
The material is SCORM compliant.
Easily add or remove training topics to fit your business needs.
Includes a reporting function that allows an administrator/trainer to track learners’ completed training topics.
You can customize the Training to fit the look and feel of your own Office SharePoint Server site.

Dev Days 2008 - Example solution package

2008-03-11T20:34:16Z

I'm speaking in the MOSS development track for the whole day in Finland Dev Days on upcoming Thursday (13.3.2008). As part of the delivery I prepared Visual Studio Solution package, which is demonstrated in each of the sessions with a little bit different twist. If you are interested, the used solution package can be downloaded from my public folder in SkyDrive. Below is direct link to the folder...

I'll write more information concerning the functionalities demonstrated on the VS solution on upcoming blog posts including instructions and guidelines to extend / modify the solution based on requirements in projects.

If you have any questions concerning the structures, feel free to add comments on this blog entry...

Create a WebCreated event of your own in onet.xml

2007-11-11T20:33:14Z

I just delivered an internal MOSS IW Ramp course in Münich and we have some discussions concerning the onet.xml and how to modify the content of the sites, which have been created using custom code directly after site has been created. You are most likely aware that during site provisioning, there's no such event available as the WebCreated, which would be raised when the web creation based on onet.xml has been done. This is quite a huge limitation, but then again, there are quite good workarounds for this.

Possible workarounds

Create your own custom site definitions using browser and export that using WSS 3.0 Extensions for VS 2005. As part of the export process, the tools generate the necessary code and associations to be used. Unfortunately the extensions do not support WCM enabled sites, so it cannot be used in publishing sites.
Use ExecuteUrl element to redirect the user to custom aspx page after the site has been created to be able to customize the site. Your custom aspx page might be located under the _layouts folder and there for we can easily point to that one using the xml elements within the onet.xml.
Create the WebCreated event using the powerfull feature framework. I'll declare the steps below for more detailed information.

Steps for WebCreated event using feature receiver

Step-by-Step guide for manual creating of WebCreated event are the following:

Create feature to deploy the default.aspx to root of the site using Module events
Create feature with feature receiver class – This is used for the Site Created event
Create site definition, which does not have directly default.aspx, rather use the feature developed above
Set the order of the features so that the default.aspx feature is activated before the receiver feature
In feature receiver feature, access the default aspx page, for example access the web part manager of the welcome page using following code

//look for the default page so we can mess with the web parts
SPFile thePage = curWeb.RootFolder.Files["default.aspx"];

//get the web part manager
SPLimitedWebPartManager theMan = thePage.GetLimitedWebPartManager(System.Web.UI.WebControls.WebParts.PersonalizationScope.Shared);

Final words

This was extremely quick sample, but hopefully it's useful to you. I'll try to find some time to make more comprehensive example of this.