• Part 1 – The Tools
• Part 2  – Exporting the Site
• Part 3 – Exporting the Lists
• Part 4 – Exporting the Site Columns and Content Types
• Part 5 – Wrap Up    Before I begin with the wrap up portion of this post, I want to make a correction to this series.  I was doing a bit of research today (quick comparisons, Joel Oleson’s take, deeper look at site definitions) on site templates, features, and site definitions and it struck me that the title of this series (Exporting a SharePoint Site into a Feature) isn’t quite accurate.  In reality, what I have been doing with my provided steps is creating a base site definition (simple few pages with web parts associated) and then stapled a number of features to the site definition.  There has been quite a bit of debate (see Joel Oleson’s post above) on which site provisioning method to use, each having it’s own pros and cons.  I’m not trying to tell you to choose one over the other, but do your research when deciding and find the method that best suits your (or your company’s) needs.  I hope this clears up some confusion I may have caused with the title.With that let’s continue on and walk through some of the steps for deployment and little quirks I’ve noticed.  For deployment, I use WSPBuilder to build and deploy my WSP files to the development farm.  What this ends up doing is copy my site definition files into a 12 Hive folder and deploy my features to the farm.  Site definitions stored in the 12 Hive (compared to stored in the database when customized through the UI or site templates) gives a performance gain.  On the downside site definitions are not (easily) updateable once deployed.  I say that because you technically can update your site definition, but it requires deleting and recreating your site if it has been provisioned anywhere.  With my current project we are only deploying one instance of each site definition to each environment and have backup software to facilitate easy migration of data from the old to new instance.  Hopefully your site definition remains fairly static and you only add functionality or modifications through new or updated features (which can be easily upgraded.)Once you have your WSP deployed, you can provision an instance of your site definition by creating a new site (or site collection) from your site settings page (or central admin for site collection.)  In your site definition onet.xml file, any features that you have placed in the <SiteFeatures> or <WebFeatures> elements will be “stapled” or automatically added and activated upon provisioning.  Below is a reduced list, but I have features to add web parts, lists, and content types among other things.

  One thing to note about my features.  The feature “Messaging Security Groups” is commented out.  The reason for that is that that feature creates a number of SharePoint groups (composers, approvers, etc) and assigns them permissions to the site being created.  However, the owner of these groups happens to be the Site Owners group.  Because I am not inheriting security from the parent site, new Site Owner, Member, and Reader groups are created.  This is an issue because those new groups are created after my features have been stapled.  This means that I must manually activate this feature after the site provisions process has occurred.  If anyone knows a good way around this please let me know.

  A few other things I’ve noticed during development.  When using the methods described in this series to export an instance of this site definition you will get some duplicate entries in the site definition files, particularly when it comes to web parts assigned to pages in the onet.xml.  I would recommend updating the original site definition (by hand or copying over only the changes from a new export) as a workaround.  Also, I have a few web parts that provide and consume connections to each other on various pages.  I haven’t found an easy way to configure those connections in code.  Some suggestions were found, but I was unable to get them working.  Instead I manually assign the connections once the page has been provisioned.  Again if any know of a way around that please let me know.

  And so I draw to a close this series.  Thanks for reading along.  Hopefully it gives you some pointers and insight into creating, exporting, and maintaining a site definition and associated features.  Drop me a comment if you have any questions, suggestions, or input.

  – Frog Out

• Part 1 – The Tools
• Part 2  – Exporting the Site
• Part 3 – Exporting the Lists
• Part 4 – Exporting the Site Columns and Content Types
• Part 5 – Wrap Up

If nothing else, this blog post will win the award for longest title that I’ve written yet.  Joking aside, It’s time to put one of the finishing stones in place for this series.  So far we’ve exported the site and lists, now it’s time for the site columns and content types.  The tool we’ll be using this go around is the Imtech Fields Explorer.  The process is fairly straight forward so let’s dive in.

Launching the field explorer tool, you’ll first be prompted to specify your SharePoint site URL and click Open.  You’ll see entries for this site’s content types, site columns, and lists.  Strangely (at least in the v1.3.0.0 version I’m using) I am not able to export lists.  Not sure if this is intended functionality or just features yet to be implemented.  Either way, select the content types and site columns to be exported.  You can also view detailed information about the individual entries, similar to other products such as SharePoint Manager.

     Click Export once you’ve selected your items.  If you’ve selected both content types and site columns, the export will occur in two phases starting with content types.

     Select the destination file location for the “Content Types.xml” output.  I typically go with the desktop for convenience of loading into Visual Studio (or favorite text editor) when complete.

     You’ll receive a success screen when that completes.

     Follow the same procedure for site columns.

     Now that you’ve got your output files, open them alongside your WSPBuilder solution.  The Columns.xml file is fairly simplistic.  It will detail all of the properties and metadata used to define a site column.  Copy all of the <Field> elements into the elements.xml file of a feature for deploying your content types (a blank feature in WSPBuilder will suffice.)  I’ve only chosen one column for the example below, but you’ll more than likely have many more.

     Next open the Content Types.xml file.  For content types, so far I’ve found only the <Content Type> elements to be necessary while the <XmlDocuments> elements can be left out.  If anyone knows the <XmlDocuments> to be required for some reason let me know.  Copy the <Content Type> elements and their child elements into the same elements.xml file as above.  The <FieldRef> elements will link to the <Field> elements via the GUID.

     Now if you remember from the end of part 3 of this series we talked about needing to add in the content type and site column definitions to our list definition’s schema.xml file as well.  So while we’re copying these definitions into the elements.xml file above, also add them to the appropriate schema.xml files for your lists.  Only the content types and site columns belonging to that list definition will need to be copied over.  In the end you’ll have something similar to the below example for the list schema.xml file.

And with that we’ve reached the final step of our exporting process.  I’ll be putting together a wrap up post on some caveats that I’ve run into thus far and other things to look out for along the way.  I’ll also do a quick bit on actually deploying the site template for use.  Thanks for reading along so far.  Post any comments or questions you have.  Until next time.

-Frog Out

• Part 1 – The Tools
• Part 2  – Exporting the Site
• Part 3 – Exporting the Lists
• Part 4 – Exporting the Site Columns and Content Types
• Part 5 – Wrap Up

So let’s recap where we’re at with this series.  Part 1 was about the tools I’ve been using to export a SharePoint site to a  feature, part 2 exported the base (pages, web part settings on pages, etc) of the site template, and now part 3 will be exporting SharePoint lists into our feature.  The tool we’ll be using time around is the MOSS Feature Generator (previously called CT Feature Creator among other names.)

As I stated in part 2, I prefer the output from the MOSS Feature Generator to that of the SharePoint Solution Generator 2008 because it required less modifications to fit into my WSPBuilder solution.  When you launch the tool, click File > New > ListTemplate Feature.  Next specify your site collection Url, the individual site that contains the lists to be exported, and the list itself.

     The next screen contains a whole host of boxes, but we’ll only touch on a few of the more important ones.  Obviously you’ll want to specify a Name and Description for starters.  Next take a look at the Type (first red box below) box.  The value will typically be the base list template id that your list is already inheriting from.  Read this post for a little explanation on each template id.  As you’ll see, 100 is the generic list template id.  Since we’re trying to create a new list template, you’ll want to create a unique id.  I typically choose values above 10000 since the out of the box list template id’s don’t currently go that high.  Feel free to come up with your own system.

The other box I’ll highlight is DisallowContentTypes.  If you’re using content types on your list (and I recommend doing so for organization and consistency sake,) then you’ll want to pay attention to this later on.  I haven’t found a way to set this during the export process, so we’ll take care of that after placing it into our feature later on.

Referring to our picture from part 2 on the solution layout, you’ll want to take your output files and place them into your solution as seen below.

    Next, open the elements.xml file.  First thing to notice is that I have added some additional markup that you won’t find in the output from our list template creator.  I’ve added <ListInstance> and <Module> nodes so that my list template is instantiated within my feature.  Feel free to model your file similarly, but not necessary.  Lastly, make sure the Type (and TemplateType if you add the list instance) value is a unique value.

Next, open your feature.xml file.  The only modification I have done here is make the feature scoped to the web since a list lives on an individual site (web) instead of at the site collection (site) level.

     The last (and probably most important) file is the schema.xml one which defines the infrastructure of our list.  As you’ll see below, I’ve outlined the addition of two key pieces.  First is the EnableContentTypes attribute of the <List> element which has been set to True so that we can have custom content types.  The second highlighted piece is the definition code for our custom content type.  Don’t worry if you don’t have (or know how to get) that XML snippet.  I’ll be covering that in part 4 of this series.  For now though, you have a rough sketch of your list template.

     As a quick aside, I’ve noticed one thing by working with the schema.xml (and onet.xml from the site template in part 1) file very frequently.  When I need to make a change to these files (add a fieldref, change view query, etc) I’ve become faster and more efficient at editing the raw file versus updating through the UI and exporting a new copy.  Reminds me of my time working with Unix and VI at a previous job.

So there we have it, second piece of our site template exported into our feature.  Part 4 will be focusing on exporting site columns and content types.  In the past that used to be a very complex and hard to manage portion of the process, but with new tools that is not the case anymore.  Stayed tuned for that installment and in the meantime post and comments or questions you may have.  Thanks for tuning in.

-Frog Out

• Part 1 – The Tools
• Part 2  – Exporting the Site
• Part 3 – Exporting the Lists
• Part 4 – Exporting the Site Columns and Content Types
• Part 5 – Wrap Up

Took a little longer to get to part 2 than expected with being gone last week on vacation and client work this week.  Quick recap for everyone on what we’re trying to do here.  Scenario would be that you’ve already built and customized a SharePoint site using the web UI (edit page, add web part, create list, create site columns, etc.)  Now we want to be able to capture that site and put it into a SharePoint feature (and solution) so that we can easily re-deploy it say for disaster recovery, migrating between development environments, or any number of other needs.

For a reference on any of the tools to be used, please read part 1.  The first thing you’ll want to do is create a WSPBuilder solution, preferably placing it under source control.  My coworker Kelly Jones and I tossed around the idea of writing up a guide for how to create the infrastructure for setting up SharePoint development environment, perhaps someday you’ll see a post on that.  For now though, check out this introduction to WSPBuilder or drop me a line if you need help getting started with WSPBuilder.  Most of my experience with it has been hands on so I don’t have too many references for getting started with it.

Once you have your WSPBuilder solution created, we’ll use the SharePoint Solution Generator 2008.  This tool will export our site into a Visual Studio solution to give us a starter base.  Run the tool (on a SharePoint server in the farm, very important) and select Site Definition.

Next Select the site to be exported.  In my case I wish to export the Messaging Site which is a subsite of Store Portal.

     Once you have selected the site, you may choose to export lists contained on that site.  I have chosen to export all of my lists but that is not necessary.

Last, select the location to output the generated solution file to and give it a name.  I leave the defaults.

     The solution generator will show you a progress bar and indicate any errors that may come up during the export process.  I have yet to run into any errors in all my times using the tool.

     Once the export has completed click on the link to open the folder containing the solution that was generated.

Taking a look at the solution file, we’ll see a couple of things.  First is the site template folder.  This contains all of the .aspx pages, the onet.xml (more on that in a later part of the series), and instances files for the lists exported.  Note: files below were from a previous export, so you won’t see some of the same folders for lists.

      You’ll want to place these files into your solution file similar to how I’ve done below.  While you can copy in the list folders into your features folder, I’ve found that the MOSS Feature Generator does a better job encapsulating all of the required information in a much smoother fashion.  So for now hold off on copying those list folders unless you’d like to toy around with how they work.  You’ll want to rename some files (ListDefinition.xml becomes elements.xml, etc) and modify some values to be more in line with the defaults used by WSPBuilder.

There you have it, you’ve exported your site into a WSP Solution and with minimal effort.  In part 3 I’ll dive into the MOSS Feature Generator and show you how to export your lists directly into feature folders.  Part 4 will be the Imtech Fields Explorer and how to export site columns and content types.  I’ve not yet planned out if there will be any further parts to this series beyond the four, but I imagine there will be at least a post or two more about advanced items.  As always I appreciate any feedback, suggestions, questions, or comments from my readers.  Let me know if there’s anything I can help with.  Until next time.

-Frog Out