Creating Features which contain custom Content Types or file provisioning modules requires developers to write a lot of XML based on the wss.xsd. Content types require custom column and content type definition files, along with the proper creation of the content type IDs. File provisioning modules require the creation of module elements which contain the information that will help properly push the files into the correct lists when the Feature is activated.

This XML can be fairly daunting, time consuming, and frankly, not very exciting for developers who just want to test their code. This holds especially true for developers who are writing custom Features based on SharePoint's Publishing Feature, and this is why I created SPSource.

SPSource helps by alleviating the need for developers to write these files by allowing them to use the SharePoint UI and SharePoint Designer (SPD) as the source for the files defined in the module elements, along with custom content types, and is meant to be integrated with (and has been tested with) WSP creation tools such as WSPBuilder, STSDev, and the WSPProjectTemplate as either part of the build process, or separately as a CMD file at the root of the project. By using the UI and SPD, items can be created and tested rapidly, then compiled into the WSP for deployment using familiar tools.

Executing BEFORE the creation of the WSP, any file that can be created using SharePoint Designer in a document library, and any site content type created in the SharePoint UI can be targeted and pulled down into Visual Studio for addition in a pre-existing Visual Studio WSP project. SPSource will also create the file provisioning modules and site Content Type/Column definition files, as well as the lines needed in the ElementManifest section of the Feature.xml file.

Some examples of how SPSource can help:

• Completely define a custom Publishing Feature using SPD and the SharePoint UI, creating the master pages, page layouts, content types, style sheets, and images directly in the content database. Once at a point where it's ready for deployment, run SPSource against the project and pull everything into a pre-existing WSP. If changes are needed in the markup, make them using SPD, and re-run SPSource. The files in the WSP will be updated and ready for a solution upgrade.

• Implement a class on an ASPX page (code behind) in SPD, and code that class in Visual Studio, or add custom server controls to the markup in SPD. Push your assembly directly to the GAC or bin as part of the build process, and the code-to-test time is much faster, as the markup files are already in the content database. Once everything is set, run SPSource again the project, and pull everything together into the WSP.

• Add a custom Content Query Web Part (or RSS) .webpart file to the web part gallery, and change the properties and settings for the new CQWP via the UI and SPD to use custom XSL files that you add to the Style Library/XSL Style Sheets folder. Create new ItemStyles, change the Headers, or add new parameters to the Main XSL. The XSL files can be updated quickly using SPD, and changes can be seen right away. When all is ready for integration into the WSP, execute SPSource against the new files and create a new Feature for the new web part in minutes.

Eventually, I hope to get SPSource working with ListInstances and Workflows, but for right now, it only works with Content Types and Modules.

Check out this screencast where I create a custom Publishing Feature, with a new content type and page layout, execute SPSource on my StsDev Visual Studio project, package it all up in a WSP, and deploy in less than 15 minutes!

SPSource Publishing Feature Demo

Here's a short walk-through example of how SPSource works:

In the 'design' site, create a new Content Type for a Publishing page using the SharePoint UI, adding some new columns

In SharePoint Designer, create a new Page Layout based on the Content Type which was just created

Still in SharePoint Designer, add the new content field controls, a web part zone, and some other markup to the new Page Layout, saving it to the 'design' site Master Page Gallery
 


Now, over in a Visual Studio project, which in this example is based on StsDev, create a new Feature, and create some new Folders in that Feature. The folders aren't important in this case, they just allow for some organization.  SPSource has been tested using WSPBuilder, StsDEv, and WspProjectTemplate, but the type of project in Visual Studio really doesn't matter. It just needs to follow the 12Hive folder structure, which means SPSource does not work with VSEWSS.

In each folder, create a new file with the file extension '.spsource'.  This file extension is important, as the SPSource utility looks for these files to work it's magic.  The SPSource files are nothing more than a type of XML file and are what I call 'reverse manifests' as they are based on the same syntax used to push things into SharePoint, but in the case of SPSource, are used to get things out of SharePoint.

The SPSource file for the Content Type is just like a Content Type definition file, and is even based on the same schema. All we need is the name of the custom Content Type we want to have included in the WSP

The SPSource file for the custom Page Layout is also just like a provisioning module file used to put files into SharePoint. We just need to tell it the source list URL, and the file to include in the WSP

At the root of the Visual Studio project, I've got a CMD file that contains the information needed to execute SPSource


Source of CMD file

After SPSource is executed, there will be some new files in your Visual Studio project.

In the ContentType folder, there are now files for both the Content Type definition, as well as the column definitions.
Content Type definition:

Column definition:
 

The ASPX page in the PageLayouts folder is the same as what we added in SharePoint designer

The pagelayouts.Provisioner.xml file is the provisioning module file needed to put the custom Page Layout in to the correct location when the Feature is activated

The two *.ElementManifest.xml files are there so you have the lines needed to add to the Feature.xml file in the ElementManfiests section.  These lines are not automatically added to the Feature.xml as to provide greater flexibility by you to distinguish what gets included in the Feature.

After I add the lines to the Feature file:
 

Now I can build my project to compile the WSP and deploy it to the 'development' site.  SPSource can also be integrated with the MSBuild process to allow for updates to the files added by SPSource before the WSP is compiled.  This allows the WSP to be upgraded using items changed in the UI and SharePoint Designer.

After the solution is built and deployed, the Feature can be activated, and the pages will be added to the Master Page Gallery
 

Master Page Gallery


When I create a new page, the new Page Layout is available in the list, as expected
 

and, the page looks the way it should

Give SPSource a try, and see how much more efficient your Visual Studio WSP creation process can be!