Maxime Bombardier - SharePoint Architecture & Development : Site Definitions and Features

Deploying resource files across a farm

MaximeB — Sat, 26 Apr 2008 16:19:01 GMT

I've been looking a little bit more on finding the easiest way to deploy resource files (.RESX) in the App_GlobalResources directory and I found various solutions that includes Features and Timer Jobs to synchronize these resource files. Mikhail Dikov has a very good article explaining different process and types of resources.

However, I find that having features and timer jobs that copy files aren't very elegant and also impractical when you want to add a farm server, when you extend a web application (new zone), etc. While we could still develop something around it, I couldn't find an elegant solution.

In fact, I think the only elegant solution would be for the WSP to deploy App_GlobalResources correctly and that'd be the end of it. Note that you can use WSP to deploy resources in the 12 hive for all Web Applications and also "feature resources". Since I didn't find a way to have that elegant solution, I reverted to asking myself "How did we do it with out of the box Publishing Sites?". The answer is simple, all resources in the ...12\Resources directory are ALL copied in the App_GlobalResources of each web application during the standard Web Application creation (or extension) process.

This means that simply copying your Resource files in the 12\Resources directory will automatically deploy your resources when you create a web application, extend a web application, and even when you add a server in the farm. Now the next question was "How do I update my resource files?". First of all, you will need to upgrade your WSP with your updated Resource files. This will copy the RESX in the 12\Resources directory again. After this, you will need to run "STSADM -o CopyAppBinContent" on all servers in the farm.

Now, there are 2 things that I find "less elegant" in this solution, one that is fixable, one that depends on your architecture:

First of all, running that command on all servers isn't fun for your automated deployment scripts since it would require either doing it manually on all servers or use a remote execution (like PSEXEC) process on all servers. You would either use a CMD with a list of servers (not very dynamic), or create a command that lists all farm servers. I'll outline a solution a bit further.
For the second, it depends how you want your architecture. If you only have one portal, it's fine to deploy it centrally. If you have more than one, it will depend if you "mind" if all resources are available on all web applications. However, in an Intranet scenario, it's probably very acceptable. If you are an ISP, I would stay away from this solution altogether and you will unfortunately have to resort to a less interesting scenario.

What I ended up creating for executing remotely the STSADM command on all servers was of course another STSADM :)! I'll soon create a post with the outline of this STSADM (and add the link here). For now, the extension does the following:

Accepts a parameter with quotes that includes the command that needs to be executed on all servers. I also noticed that you cannot have a parameters that includes "-o" between quotes so I might modify my command so that it accepts an input file that lists the command to be executed on all servers (just to be safe I can catch all parameters).
Retrieves the list of servers (of which the server role isn't "Invalid" like the database server)
For each server, I add an entry in the Central Administration's "Administrator Tasks" list that describes the command (title) with the server name in it, and in the description, I add the command to execute
For each server, I create a Timer Job with a schedule of SPOneTimeSchedule. That will essentially execute the job now on each servers and they will automatically delete themselves.
On each server, when the Timer Job kicks in, it goes back in the Central Administration, reads the Administrator Tasks and find the entry with the "local" server name in order to read the Description column and execute the command defined there

The original command also check that there isn't a timer job and task with the same name prior to executing. Last, if the command doesn't execute successfully on a server, the task isn't deleted and stays on the Administrator Tasks list that shows on the first page of the Central Administration. This allows to have a visual knowledge that the task didn't execute correctly.

Cheers!

Maxime

Creating SharePoint webs with Excel and STSADM

MaximeB — Sat, 22 Mar 2008 16:03:43 GMT

This is a follow-up to my Site Definition Helper scripts post. As described in that post, we were looking at making it simple to create multiple webs. While you can use a site definition with a PortalProvisioningProvider to do this, if you have variations, you cannot use it since most of your webs will be under a variation and the provider doesn't create variations.

Before we were using Site Definitions, we had a nice STSADM extension that was creating webs + pages, repairing what it needed such as AvailablePageLayouts and WelcomePage parameters. Fortunately, a good Site Definition design made that obsolete except for creating the "starting webs" as well as for creating test pages (but you could still provision the test pages with a Site Definition anyway). Since we have Site Definitions, we should use the "STSADM -o CreateWeb" command since it's easy to use and it works fine.

The command requires the following parameters:

url
sitetemplate
title
lcid

Ideally, it would be nice to have a nice Excel file that contains all of these in a much nicer table format than what you would get in a CMD file. And that's exactly what we did! The Excel contains the same columns that are required for the command to execute, we export it to an "Text (MS-DOS)" format (very important if you want your locale to work correctly), and then run a "For" loop in a CMD file that reads the exported TXT file :

   1: FOR /F "eol=; tokens=1,2,3,4 delims=    " %%i IN (Data/CreateWebs.txt) DO (   2:     @ECHO ----[ Creating "%%i" ]--   3:     %stsadm% -o createweb -url %url%%%i -sitetemplate %%j -title "%%k" -lcid %%l   4: )   5:  

Here's the complete script which requires the variable.cmd available on this post:

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5:     6: @ECHO %separator%   7: @ECHO Create Website Structure and Content.   8: @ECHO %separator%   9:    10: :CREATEWEBS  11: @ECHO:  12: @ECHO %separator%  13: @ECHO Create Site Structure  14: @ECHO %separator%  15: @ECHO.  16:    17: FOR /F "eol=; tokens=1,2,3,4 delims=    " %%i IN (Data/CreateWebs.txt) DO (  18:     @ECHO ----[ Creating "%%i" ]--  19:     %stsadm% -o createweb -url %url%%%i -sitetemplate %%j -title "%%k" -lcid %%l  20: )  21:    22:    23: :IE  24: @ECHO %separator%  25: @ECHO Operation completed  26: @ECHO %separator%  27:    28: IF NOT "%1"=="noie" start iexplore %url%

You can download all the scripts here :

Big thanks to Cristian Deschamps from Orckestra for the help on this. Happy web creation!

Maxime

Feature properties, web.config, and feature properties inheritance

MaximeB — Sat, 08 Mar 2008 15:20:23 GMT

My team ran into this last week where I asked to have some properties available to the feature. It was the first time that we were allowing properties in the features and I hadn't given much explanation as to how I was seeing the property definition. They are all experienced ASP.NET web developers so the first thing that popped into mind was to use the web.config to store properties.

While this is a common practice in ASP.NET, experienced SharePoint feature or site definition makers will know that there is also a way to use properties in the Xml directly but I'll get back to you. First, let's handle the web.config; will it work? Well it will work when your feature is activated through your web site's interface. However, when you use an STSADM to create Web,the web.config will not be in the same process and your feature will not work.

So how do we do it, we use <Properties> and <Property Key=... Value=...> xml elements:

<Feature
Id="11111111-1111-1111-1111-11111111111"
Title="Location Services"
Description="This Feature contains lists and parts that let you link location data to your customer lists."
Scope="Web">
<ActivationDependencies>
    <ActivationDependency
      FeatureId="11111111-1111-1111-1111-111111111111" />
</ActivationDependencies>
<Properties>
    <Property
      Key="Color"
      Value="Blue"/>
    <Property
      Key="Shape"
      Value="Triangle"/>
</Properties>
</Feature>

In your feature event, you can then retrieve the feature's property values by "properties.Feature.Properties" and this will return an SPFeaturePropertyCollection object with your properties. An interesting fact is that you can use the "Properties" element in 2 places : in the feature.xml itself and in the onet.xml (site definition). How it works is that your SPFeaturePropertyCollection will contain the sum of all properties defined at the 2 areas. If a property's defined at both areas, it will use the value in the onet.xml file.

Note that you cannot set property values in the ActivationDependency element. While activate dependencies will activate a feature if it's hidden, it's still just a mechanism to enforce a dependency. If you depend on a non-hidden feature, it requires to be activated prior to activating yours.

Maxime

Feature Stapling is really just for out of the box site definitions

MaximeB — Sat, 08 Mar 2008 15:02:56 GMT

A couple months ago, when I started reading about Feature Stapling on blogs (I don't recall the MSDN documentation having been updated at the time but it is now), not only did I think that it was a mechanism to attach a feature to a site definition (it's true) but it was also touted as a way to update a site after it has been deployed. As a little note, Feature Stapling is basically a feature that contains FeatureSiteTemplateAssociation nodes that attaches a FeatureId to a Site Definition name and configuration.

Now I have carefully worded the last sentence. it's still true, you can use it to update a site after it has been deployed, however, what I didn't know is that Feature Stapling will ONLY work on new site that will be created. Sites already created will not have the feature activated on it and will require a different process (custom).

Now that's a little bit more interesting because Feature Stapling simply adds a <Feature Id=... /> tag to site, which you can do in the ONET.xml anytime unless it's an out of the box Site Definition. Since modifying those definitions isn't supported, Feature Stapling is then the mechanism to attach custom features to OOB definitions. For your own custom site definitions, while you can still use stapling, you can also simply modify your custom ONET.xml and it will do the same.

Now, what do you really do to attach the feature to created sites (which is really what you want to do)? Since Feature Stapling or site definition modifications only works for future sites, you need to activate the feature "now" to all existing sites. The best way is to create a custom STSADM extensions that will run through all sites and subsites, validate if the feature's (SPWeb.Features) is there on the SPWeb. If it is, keep going, otherwise, add the feature to the collection and update (and dispose) the SPWeb object. You can use something simple in the lines of :

   1: using(SPSite site = new SPSite(http://servername/))   2: {   3:     foreach(SPWeb web in site.AllWebs)   4:     {   5:         if(web.Features[featureId] == null)   6:             web.Features.Add(featureId,true);   7:     }   8: }

In summary, you absolutely have to use Feature Stapling on out of the box site definitions to add your custom features to it. For your custom site definitions, you can either modify your ONET.XML file or use Stapling. For already created sites, create an STSADM extension to activate that feature on all of them.

Maxime

(March Update) Site Definition developer helper scripts

MaximeB — Sun, 24 Feb 2008 16:13:30 GMT

The first thing you realize when playing with Site Definitions is that "IISRESET" is your next best friend. However, if you plan on deleting your old site collection and create a new one (to test a RootWeb / Site Collection site definition), it's very long to re-open up the Central Administration and do it through the interface since you'll have to reload both the CA and your web site.

Since I'm no master of Site Definitions, I'm still doing a lot of resetting because I like to understand each portion of the site definition. I started by creating a small DOS Batch File (CMD) that was copying my xml, deleting the site collection and recreating it through STSADM. If no error is found, I start Internet Explorer on my URL. Basically, I can drag this CMD file on my Quick Launch, click it, go take a coffee and when I come back, the site will be loaded (unless I made a mistake in the XML!).

Also, I'm using Visual Studio to edit Site Definitions since I am storing them in Team Foundation Server. Why VS? Well since playing with Site Definitions requires that you open up a few XML (the WebTemp*, the onet, the feature.xml that you are linking, etc.), it's nice to have a single GUI with all the editing tools and structure. Of course, the Site Definition Viewer is practical for any Site Definitions, but it's not an editor so VS was my choice.

If you create it, you end up with a structure like this (more or less) picture :

As you can see, you may have a custom web.config as well as RESX files to put in App_GlobalResources. Of course, when you deploy to your production server, you won't use these scripts and rather a WSP that will apply web.config modifications through SPWebConfigModification. This script is merely to have a quick and dirty copy for development box before you are ready to create Builds.

In the root, you can see 4 scripts :

Variables.cmd contains all the required variables to function. You should check that it matches your environment before running the other script.
CopyFiles.cmd will copy your 12 hive, your web site folder (dubbed 80), and your RESX files before any other scripts is ran
CreateSiteDefinition.cmd will call CopyFiles and then delete + create a site collection with the variables defined in Variables.cmd
InstallFeature.cmd is simply a helper that will copy your 12 hive and then install -FORCE all features in the script. If you add a feature, add the command line there.

**March Update** :

I added more scripts :

CreateWebs.cmd (to create a series of web, explained here)
DeleteWeb.cmd (to delete webs (in order to launch another creation))
GAC.cmd (to add DLLs to the GAC)
Go.cmd (to have a menu of options)

The previous scripts have been updated as well and are cleaner. Here's a screenshot of the Go command:

**/End March Update**

I'm still working on it and plan to add functionalities such as "CreateWeb" list from an Excel spreadsheet **March Update** : read the post here for the CreateWeb **/March Update**. That basically replace most of my "SiteBuilder" STSADM extension (except for creating content pages!) and simply runs a series of STSADM -o CreateWeb commands with an input file that you edit in Excel. You can download the current version here:

Here's the included files:

Variables.cmd

   1: @ECHO OFF   2: IF "%variables%"=="true" GOTO END   3:     4: @SET separator=ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ   5:     6: @ECHO %separator%   7: @ECHO Creating variables   8: @ECHO %separator%   9:    10: :VARIABLES  11: @SET variables=true  12: @SET stsadm="C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN\stsadm"  13: @SET lcid=1033  14: @SET description="Test Custom Portal"  15: @SET title="Test Custom Portal"  16:    17: @SET owneremail=%USERNAME%@%USERDNSDOMAIN%  18: @SET user=%USERDOMAIN%\%USERNAME%  19: @SET sitetemplate="MyCustomSiteDefinition#0"  20: @SET url=http://%COMPUTERNAME%:80  21: @SET hive12="C:\Program Files\Common Files\Microsoft Shared\web server extensions\12"  22: @SET wwwsites="c:\inetpub\wwwroot\wss\VirtualDirectories\80"  23: @SET gacutil="E:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil"  24:    25: :END

CopyFiles.cmd

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5:     6: @ECHO %separator%   7: @ECHO Copying features and site definitions to 12 hive   8: @ECHO %separator%   9:    10: CD 12  11: XCOPY /y /s *.* %hive12% > nul  12:    13: @ECHO %separator%  14: @ECHO Copying Web.config and resources files  15: @ECHO %separator%  16:    17: CD ..\80  18: XCOPY /y web.config %wwwsites% > nul  19:    20: CD ..\App_GlobalResources  21: XCOPY /y *.* %wwwsites%\App_GlobalResources > nul  22:    23:    24: IISRESET  25: @ECHO.

CreateSiteDefinition.cmd

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5: @CALL CopyFiles.cmd   6:     7: @ECHO %separator%   8: @ECHO Deleting Site Collection   9: @ECHO %separator%  10: %stsadm% -o deletesite -url %url% -deleteadaccounts false  11:    12: @ECHO %separator%  13: @ECHO Creating Site Collection  14: @ECHO %separator%  15: %stsadm% -o createsite -url %url% -owneremail %owneremail% -ownerlogin %user% -lcid %lcid% -sitetemplate %sitetemplate% -title %title% -description %description%  16:    17: IF ERRORLEVEL 0 GOTO IE  18: @ECHO %separator%  19: @ECHO Error while deleting or creating Site Collection  20: @ECHO %separator%  21: SET ERRORLEVEL=-1  22: pause  23: GOTO:eof  24:    25: :IE  26: @ECHO %separator%  27: @ECHO Operation completed  28: @ECHO %separator%  29:    30: IF NOT "%1"=="noie" start iexplore %url%

InstallFeature.cmd

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5: @CALL CopyFiles.cmd   6: @CALL GAC.cmd   7:     8: @ECHO.   9: @ECHO %separator%  10: @ECHO Forcing features installation  11: @ECHO %separator%  12: @ECHO.  13:    14: @ECHO --[ Installing MyCustomFeature ]----------------------------------  15: %stsadm% -o installfeature -name MyCustomFeature -force  16: IF NOT ERRORLEVEL 0 GOTO PAUSE  17:    18:    19: :PAUSE  20: @ECHO %separator%  21: @ECHO Error while installing last feature  22: @ECHO %separator%  23: PAUSE

CreateWebs.cmd

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5:     6: @ECHO %separator%   7: @ECHO Create Website Structure and Content.   8: @ECHO %separator%   9:    10: :CREATEWEBS  11: @ECHO:  12: @ECHO %separator%  13: @ECHO Create Site Structure  14: @ECHO %separator%  15: @ECHO.  16:    17: FOR /F "eol=; tokens=1,2,3,4 delims=    " %%i IN (Data/CreateWebs.txt) DO (  18:     @ECHO ----[ Creating "%%i" ]--  19:     %stsadm% -o createweb -url %url%%%i -sitetemplate %%j -title "%%k" -lcid %%l  20: )  21:    22:    23: :IE  24: @ECHO %separator%  25: @ECHO Operation completed  26: @ECHO %separator%  27:    28: IF NOT "%1"=="noie" start iexplore %url%/fr/fcdq/

DeleteWebs.cmd

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5:     6: @ECHO %separator%   7: @ECHO Delete Website Structure and Content.   8: @ECHO %separator%   9: @ECHO.  10:    11: %stsadm% -o deletesubwebs -url %url%/fr -recurse true  12: %stsadm% -o deletesubwebs -url %url%/en -recurse true  13:    14: :IE  15: @ECHO %separator%  16: @ECHO Operation completed  17: @ECHO %separator%

GAC.cmd

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5:     6: @ECHO %separator%   7: @ECHO GAC Util   8: @ECHO %separator%   9: @ECHO.  10:    11: IISRESET  12: @ECHO.  13:    14: @ECHO --[ Installing MyCustomDll.dll ]---------------------------------  15: %gacutil% -i "C:\Temp\bin\MyCustomDll.dll" -f /silent  16: IF NOT ERRORLEVEL 0 GOTO PAUSE  17: @ECHO.  18:    19: GOTO:eof  20:    21: :PAUSE  22: @ECHO %separator%  23: @ECHO Error while installing last DLL  24: @ECHO %separator%  25: PAUSE

Go.cmd

   1: @ECHO OFF   2: cd /d %0\..    3:     4: @CALL Variables.cmd   5: Color 0A   6: CLS   7:     8: :MENU   9: @ECHO.  10: @ECHO.  11: @ECHO.  12: @ECHO.  13: @ECHO %separator%  14: @ECHO MyCustom Sharepoint website  15: @ECHO %separator%  16: @ECHO (1) Install Features  17: @ECHO (2) Create Site Definition   18: @ECHO (3) Create Webs  19: @ECHO (4) Copy Files  20: @ECHO (G) GAC DLL  21: @ECHO (D) Delete Webs  22: @ECHO (x) Exit  23: @ECHO.  24: CHOICE /C 1234567GDX /M "please make a choice : "  25:     IF ERRORLEVEL 10 GOTO:eof  26:     IF ERRORLEVEL 9 GOTO DELETEWEBS  27:     IF ERRORLEVEL 8 GOTO GAC  28:     IF ERRORLEVEL 4 GOTO COPYFILES  29:     IF ERRORLEVEL 3 GOTO WEBS  30:     IF ERRORLEVEL 2 GOTO SITEDEFINITION  31:     IF ERRORLEVEL 1 GOTO FEATURES  32:    33:    34: :FEATURES  35: @ECHO.  36:     @CALL InstallFeatures.cmd  37: GOTO:MENU      38:       39:    40: :SITEDEFINITION  41: @ECHO.      42:     @CALL CreateSiteDefinition.cmd  43: GOTO:MENU      44:       45:    46: :WEBS  47: @ECHO.  48:     @CALL CreateWebs.cmd  49: GOTO:MENU      50:       51:    52: :DELETEWEBS  53: @ECHO %separator%  54: @ECHO.  55:     @CALL DeleteWebs.cmd  56: GOTO:MENU      57:    58:    59: :COPYFILES  60: @ECHO %separator%  61: @ECHO.  62:     @CALL CopyFiles.cmd  63: GOTO:MENU  64:    65:    66: :GAC  67: @ECHO %separator%  68: @ECHO.  69:     @CALL GAC.cmd  70: GOTO:MENU

Cheers!

Maxime

Deployment lifecycle when using Site Definitions and Features (including post production day)

MaximeB — Sat, 23 Feb 2008 16:14:22 GMT

Summary

As you have noticed, I've changed my latest SharePoint focus to look at Site Definitions (and obviously Features but I played with them a lot prior to this). The reason for this is that I was looking at the "best" way to deploy artifacts for SharePoint WCM portals. While I had a very good working solution prior to me playing more with Site Definitions, I now think that I am ready to handle the task much better. This is also a follow-up to a previous article : http://blogs.msdn.com/maximeb/archive/2008/01/13/real-life-team-based-development-for-web-content-management-with-sharepoint-2007.aspx

The reason for this is that there is no single way to deploy SharePoint artifacts. Worst, once you deployed the first time, your original mechanism may not work anymore or if it does, it's probably not what you should use! What I'll attempt to do here is to define a few SharePoint artifacts that we deploy in a Web Content Management scenario for both production day and post production day, as well as the deployment lifecycle for the developers pre-production-day and post-production-day.

SharePoint artifacts we'll cover:

Master pages
Page Layouts
CSS / JavaScripts / Images (for the masterpages and layouts)
Site Columns & Site Content Types
Library content types association
Custom Lists
Event Handlers on libraries
Feature Receivers
Timer jobs

SharePoint topics discussed:

Site Definitions
Features
Variations
Feature Stapling
Timer Jobs
Content Deployment

Why Site Definitions?

The timing of me digging Site Definitions more and this post, http://www.andrewconnell.com/blog/archive/2008/02/15/You-dont-need-to-create-site-definitions.aspx, from Andrew Connell was interesting. First of all, he's right, you do not need to create a Site Definition all the time. However, there are also general guidelines. When you look at the Publishing portal that is available out of the box, it really looks like a good sample for reverse-engineering (and believe me, I opened it often to learn stuff!). How often have you kept the original "Press Releases" sub-site or used "Blueband" or any other master for your site? What Andrew mentions is that you should create your own minimal publishing site or you can take a look at this one here on CodePlex but I suggest you still take it apart with your requirements.

Also, I'm almost always in a multilingual scenario (i.e.: SharePoint Variations) and then Site Definitions takes its full meaning. Why? well the Variation mechanism is really just a system that provision sites. It is not a copy of the source site. When the variation timer job kicks in, it will detect a new site in the source variation. When it reads it, it takes the title, the description, the URL and the Site Template (i.e.: site definition). Then it simply does a standard Create Site... with those parameters. Once that is done, it will replicate only the publishing fields of the welcome page. Last, it will provision the other publishing pages the same way and replicate only the publishing fields on those pages. Note that any customization done manually at the source, beside publishing pages and fields, will NOT be brought to the other variations. That includes libraries undefined in the site definitions, documents or images, versioning settings, workflows, and everything else you see in the user interface that isn't a publishing field!

I think my last sentence was obvious enough that if you customize something at the source, you will customize it again at the destination. While there may be scenarios when you might want this, it'll be unusual and the solution is to use Site Definitions so that the provisioning brings as much as possible.

I'll finish this section with an example: today, if you have a Publishing site with the OOB site definition and that your welcome pages aren't "WelcomeLinks", what do you do? First of all, at the source, you created a new page with your layout. Then you updated the welcome page of your site to your new page and deleted the old "default.aspx". Now all your welcome pages are not "default.aspx" but it's no big deal. When you created a 2nd variation label, all the default.aspx/WelcomeLinks are back and they are the welcome pages of your sites in that variation!! So you again updated the welcome page and deleted the default.aspx. That's not very user friendly. Also, if you wanted to ended up renaming your custom page to "default.aspx", the variation mechanism would break when trying to provision the site since it's the name for the WelcomeLinks.

As you can see, Site Definitions becomes a must when using variations.

What defines a Site Definitions?

First of all, there is no golden rule for this but here's what I personally follow to determine if I use the same definition or a new one:

A different welcome page layout
I want to pre-provision a default set of web parts in a welcome page layout
(f) I want to associate specific content types to libraries
(f) I want to allow specific page layouts creation (i.e.: a "news" only section, a "product" only section, etc.)
(f) I want to add special Site Actions for some sites
(f) I want to have a special workflow for some sites
(f) I want to update library settings for some sites

Note that the items prefixed by "(f)" are items where the delivery mechanism is Features but they are associated in some site definitions.

Also, one note that will affect your site definition architecture are Feature Stapling. That functionality is one of the very practical mechanism to apply a feature to a site definition. Unfortunately, it's also "only that". What I mean is that if you have multiple sites with the same definition, it will apply the feature on all those sites. This is great inside a single Site Collection but when your SharePoint farm contains multiple site collections (possibly for different customers), you may not want to apply a feature to all of them. Unfortunately, I do not personally know of a better solution than to create your Site Definitions "per site collection" only (i.e.: in the naming). They will still likely use the same features though.

And really, when I design Site Definitions, I created a Feature that contains all the Features that I use for ALL sites. That way, my Site Definitions are very small and only contains the customization for that site. Also, I suggest taking a look at this tool to read your sites definitions : http://blogs.msdn.com/maximeb/archive/2008/02/16/site-definition-viewer-a-windows-net-2-0-tool-to-read-site-definition-and-features-configurations-version-0-1.aspx. I also created some CMD files to automate development of site definitions and they come in handy to maximize your time. I will post them soon.

Before taking a look at the SharePoint artifacts, I need to give you a bit of background on how we get the artifacts: We set up a MOSS server only for "web integrators". The Site Collections in there contains the files directly in the database edited through SharePoint Designer. We hooked up an event on the libraries that, when a check-in is done, it brings the file in a Team Foundation Server. Then, we have someone maintaining the build process and when he get the "go" from the web integrators, he builds the feature containing the files and that is sent to the developers for updates and eventually to production.

SharePoint artifact deployment - Master Pages - Page Layouts - CSS/JS/Images

1) Pre-production "day 1"

You should create a site-scoped Feature containing your master pages and other files (pages layouts and css/js/images). Take a look at the PublishingLayouts for ideas. When this feature is activated on a site collection, it will add the file in the libraries in a ghosted format which means that there are no customization on them. Note that if you ever unghost it at the destination, your feature will never update the file after.

2) Post-production "day 2+"

We'll have to define some sub-scenarios but first, let's start that, yes, you may be able to uninstall the feature and reinstall it while using the -force command but I do not recommend it. First, as I just mentioned, if you unghosted a file, it will not be updated. So if you plan on using this technique, make sure you test first. Also, I had some issues with BlobCache with CSS/JS/GIF/JPG but only when they were ghosted, never when unghosted.

Scenario #1 Updates to some/all the files

I would suggest creating an STSADM extension that update files defined in your Feature. This extension will unghost the file and it will act as your mechanism to deploy updates. What I use is a simple extension with an Xml input file that defines the files to update. This file simply grows over time since I only append to it. It gives me an added benefit with "change management" since it's not simply a build that picked up all files and sent it in the feature which may contain an update.

Scenario #2 New files

If you have new files, you probably have a "business reason" behind. For a new master pages or page layout, is it only for a new type of site (i.e.: defined in a site definition) or would you like to apply it automatically on some/all sites? That you have a new site definition or not, you are likely to have a new feature that brings the file. This feature may contain a Feature Receiver that will do some actions with those files such as :

Assigning the master page to some sites
Allowing the page layout to be created in some/all sites
If you have a new site definition, you may want to add it in the list of available web templates

Once you have your feature, you may want to create another one to staple the first feature with your site definition (some or all of them).

For new CSS/JS/images, they are probably used by a new page layout or master to being with so they will go in the same new feature.

3) Developers Pre/Post production day

During the initial development phase "pre-production day", developers should update their environment when they need it. Since I have everything in Team Foundation, I created special CMD/Bath files for developers that helps them clean/create a site definition with some sub-sites already pre-populated. This is enough for most cases. It's clean and fast and they are up and running quickly.

"Post-production day", the site definitions will not be updated (although they can be appended), nor the features, so they should run the same script that add files in the database and install the new features.

SharePoint artifact deployment - Site Columns and Site Content types + library association

1) Pre-production "day 1"

Feature is the best mechanism to bring columns and content types. Note that the feature has to be Site scoped so it will not bring the content types to a library unless you manually create a page through the GUI or that you use a content type association feature in your site definition. You can take a look at Andrew Connell's STSADM extension for a good sample of exporting your columns/content types.

2) Post-production "day 2+"

Well we learned the hard way, since the MSDN documentation wasn't available back then, that if you add a column to a content type (in a feature), a "reinstall" of the feature will only bring the new column at the Site Collection level and it will not be replicated down to each libraries using that content type. Fortunately, the user interface works great so if you do not have many columns to add, you may simply want to document the manual update.

But you know I like automation ... so yes, we are also fortunate with the API and it replicates down the change as well. An STSADM extension that adds column + associate it to a content type can be done easily so that it reads an Xml input file with all the updates since Day 1. When it runs, if the column's already there, it simply skips it and go check if the content type contains the association to it.

3) Developers Pre/Post production day

The same process will apply for developers. However, since the "STSADM extension" isn't created until Day 1, they may either recreate their site collection or manually add the column/content types when a change occurs. In my case, since creating a site definition is scripted, it goes very fast.

SharePoint artifact deployment - Custom lists

1) Pre-production "day 1"

A custom list is defined in a feature. The definition contains the columns and types. An instance of a list is defined in a Site Definition or through the user interface. You can also populate rows of data for an instance of a list defined in the Site Definition.

2) Post-production "day 2+"

That one is tricker, you can update and reinstall the feature. However, that will only affect new list creation. I personally haven't gotten the need to add columns and data to a list post-production but I would likely need another little STSADM extension to update it.

3) Developers Pre/Post production day

Same process as the content types, if it's only a feature, then reinstall it. If it's in the site definition, run the creation script.

SharePoint artifact deployment - Event Handlers, Feature Receivers, and Timer Jobs

1) Pre-production "day 1"

All of these are class items. You may want to run code for a specific event on a library, run code when a feature's activated, or run code through a timer job at a specific time. All of them are also originally brought through a feature.

2) Post-production "day 2+"

Now, this can be either very easy or much harder depending on how "politically correct" you want to be. Technically (or less politically correct), the classes are either in the BIN or the GAC, if you need to update the code, you can simply deploy them without touching anything in SharePoint (beside an application recycling or an IISRESET). That is, only if you kept the same assembly version.

Unfortunately, if you want to be more politically correct, you'd have to change the feature, since it contains the assembly version, and reinstall it but there are cases when it seems that some references are "ghosted" somewhere in a database so it may not work. If you want to be politically correct (and normally, we should) with assembly versions, I would strongly suggest doing tests.

3) Developers Pre/Post production day

For pre-production day, it's easy, the version isn't likely to change much so you are good to deploy the DLL and reset IIS/app pool. Post production day will depend on what you chose in scenario 2.

Content Deployment with all this

As long as your site definitions, features, and assemblies are all deployed at the destination, Content Deployment will work great with your artifacts. Sounds simple but even with all my run-ins with Content Deployment, it works good in that scenario.

Hope it helps a bit. I know it's a bit sad that there isn't a "single scenario" and I'm still using STSADM extensions to do some updates, but remember, most of the updates are doable from either SharePoint Designer or the web user interface. These 2 tools works good for the updates. Unfortunately, this version of the product doesn't seem to include the fact that field WCM deployments often have a more rigid and secure environment and SPD users aren't likely to play in production or even staging. That's when we, developers, want to automate the process and that's when we create STSADM extensions to fill the gap.

Maxime

Site Definition Viewer - a Windows (.NET 2.0) tool to read Site Definition and Features configurations (version 0.1)

MaximeB — Sat, 16 Feb 2008 03:15:23 GMT

I spent a little bit on time understanding Site Definitions lately, particularly the Publishing ones like BLANKINTERNET. One very frustrating thing is to make sense of all the WEBTEMP* configurations, the site definitions, the features, the features dependencies, and the stapled features ... When you start doing Windows search on a "text containing this Feature GUID" and then you open up a bunch of Notepads, you get lost :)

So I created this little Windows application with .NET 2.0. It basically ask you for which Site Definition folder you want to read and it will then create a complete TreeView showing the following information :

All Site Definition Configurations
All Site Features as well as Web Features
All manifests files in any feature used by the site definition configuration
All receiver classes in any feature used by the site definition configuration
All stapled features to the site definition configuration
All properties for any feature used by the site definition

Other features enabled:

On the feature GUID/NAME, a tooltip will appear with its description
Double-clicking on the site definition configuration will open ONET.XML with your default XML launcher
Double-clicking on a manifest file will open the file with its default launcher (usually XML)
Double-click on a feature name will open the file with your default XML launcher
There's a configuration file if you installed your 12 folder elsewhere, you can also specify the site definition to automatically select (practical if you launch the tool often and want to read the same definition :))

** UPDATE ** : I updated the application to not show an error when the feature.xml file doesn't load. Some installations have a few empty folders and I was showing up lots of message boxes. They have been removed.

Here's what it looks like for BLANKINTERNET:

You can see here the all files (manifests) defined with the Publishing feature:

You can see here the properties for the NavigationProperties feature:

You can see that the Publishing feature also defines a receiver class (when you are doing reverse engineering of a feature to understand it, the receiver class is very practical):

Last, you can see that the PublishingSite and PublishingWeb are stapled to all BLANKINTERNET definitions (even though they are defined in the site definition anyway) :

This tool is simply there to help you read all the parameters quickly. It's working fine for me but I haven't done extensive testing and it's not doing everything. Also, I read the WEBTEMP*.xml files in 1033 (english) only but that's also configurable in the configuration file.

Maxime