Site Definitions and the SharePoint Solution Generator 2008 Part 1

SharePoint dev is a pretty new thing for me and feels pretty much like jumping into the ocean and being told to pull an ocean liner to New York (including all the pitfalls that may be encountered, like Icebergs!)

One thing I've had to do recently is to create a Site Definition for provisioning sites as part of a custom solution. A Site Definition is defined as:

“A Site Definition is a group of files that reside on the Web server and that define a unique type of SharePoint site.”

Office Web site

What this means is that if you have a custom solution that needs a list or library defined across a number of sites then a site definition is for you! The Site Definition can contain a lot of configuration to make a site very specific – for example, site columns, an announcement, and content types.

There can be a number of files that make up a site definition, but there are two key ones.  They are:

• feature.xml - defines a Feature and specifies the location of assemblies, files, dependencies, or properties that support the Feature.
• onet.xml - contain a reference to a Feature instance and default property values (i.e. all the lists that will make up the site).

For someone new to this can be quite daunting, especially, when you see the number of files, but also what is in the those files. There are methods to manually create these and update them and this is where the SharePoint Solution Generator steps in.  Some might call it cheating, but it certainly helps quickly generate Site Definitions.  Needless to say the first time I tried this tool, it still went horribly wrong!

Thanks to a colleague (Thanks Martin!) and a quick 101 I on the Solutions Generator, I got on track. 

So, before you dive into the heady world of Site Def’s, you will need a few tools.  They are:

• A SharePoint environment (preferably a test environment! Your SharePoint Administrator may have something to say is you mess up their live environment…)
• Visual Studio 2008 (or 2005 if you haven’t upgraded yet)
• SharePoint Solution Generator 2008 (or 2005 if you are using the 2005 version of Visual Studio)

Step 1: Planning

As with all dev work there needs to be some level of planning before getting going.  Thankfully if you do the planning in the correct way then it means that you can do an awful lot of the work up front.

Firstly you need to decide what lists, columns and metadata you will need for your solution.  So if you were doing a forms solution you will need a Forms Library.  If you need a document library with some additional columns then you create a Doc Lib and add add some additional columns in.  It’s worth documenting this for further reference – especially if you are working as part of a team.  A table below can be quite handy template for this:

* one important area with naming is that SharePoint names can be defined for the display name as well as an actual name.  It is important that the actual name format is constant with all areas of SharePoint.  So if there is a naming format standard that is no spaces, and no capitals then this must be followed.  The first time that an item is created within SharePoint the actual name is set.  Once this is in SharePoint it cannot be changed.  The display name can be though… for example:

You can see that the Display Name is “Test Name” but in the Web Address the name of the list is testname.  If these were the same, the the Web Address would be Test%20Name.  This is the case for Content Holders as well as Columns.

This is important especially when dealing with custom development.  If a workflow needs to be posting data to a field called testname but is reference as Test%20Name, then it will not work (GUID’s are a good way of managing these). So when creating these, it is also worth putting in the actual name first and then re-editing the name to be the display name(in C# code these are defined as DisplayName and Name).

Next Post will start the building process.