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!

We've been working on this one for a while, and it's been driving us nuts...

In the current project we're working on, we haven't been able to add any new web parts to pages, nor have we been able to edit the properties on the existing ones.  When we do, we've been seeing the three following errors:

- Cannot save the property settings for this Web Part. Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
- Unable to add selected web part(s). Exception occurred. (Exception from HRESULT: 0x80020009 (DISP_E_EXCEPTION))
- Unable to add selected web part(s). List View Web Part could not be added, list may be hidden.

Even stranger was that it was only occurring in the root web of the current site collection.

In researching the 0x80020008 error when related to web parts, the few people that have found anything have said that it could be caused by disposal of the SPContext.Current.Site or SPContect.Current.Web objects.  We looked all over our code and didn't find that we were doing that anywhere.

We switched the master page back to the default.master, and we could add and edit web parts without any issues, so we then started whittling down the server controls on the custom master page until we found three custom server controls that were present when the web part errors occur.  Taking a closer look, these three controls all had the following lines in common.

            using (SPWeb
rootWeb = SPContext.Current.Site.RootWeb) { //code }

Commenting out of the code caused the errors to go away.  What's going on here? 

Turns out that there's something that the Best Practices: Using Disposable Windows SharePoint Services Objects post and Roger Lamb's SharePoint 2007 and WSS 3.0 Dispose Patterns by Example should point out a little clearer.  If you look at the bottom of Roger's post, there's a comment by Stephen Kaye where he hits the nail on the head:

If your current context’s web is the root web of you current context’s site then the RootWeb property of the site will reference the same object return by SPControl.GetContextWeb and SPContext.Current.Web and should therefore not be disposed.

So, this means that if you are in the root web of your site collection, and you dispose of SPContext.Current.Site.RootWeb, you're actually disposing of SPContext.Current.Web.  Not good.

Here's how we changed the code to ensure that we could use the RootWeb SPWeb object, but not dispose it if the SPContext.Current.Web is the RootWeb:

SPWeb rootWeb = null; if (SPContext.Current.Web.IsRootWeb)
rootWeb = SPContext.Current.Web; else rootWeb
= SPContext.Current.Site.RootWeb; //codeif (!SPContext.Current.Web.IsRootWeb)
rootWeb.Dispose();

So, earlier I posted how I upgraded WSSv3 to MOSS.

After I completed that task, I wanted to see what it would take to turn my existing top level site collection into a publishing site, as the Publishing Feature is one of the lowest hanging fruit in the MOSS Feature stack that has the greatest benefit to both users and administrators right out of the gates.

The first thing we need to do is enable the Office SharePoint Server Publishing Infrastructure feature in the site collection features list.

Uh oh:

The logs say that access was denied activating the Publishing Resources feature and the message is 'Provisioning did not succeed. Details: Failed to provision the scheduling job definitions.  Page scheduling will not succeed.'  Then there are some other messages in the logs that say that an exception was thrown ensuring dependencies were met for the Publishing Site Feature.

According to a post I found on NetAdminTools.com, you can activate the Publishing Resources via stsadm, then click the Activate button in the site collection Features list.  This seemed to work pretty well:

Then I activated the Office SharePoint Server Publishing Feature in the Site Features list (in the Site Administration group) and the Pages list was created and the site actions menu was expanded, and there was much rejoicing (yaaay)

BUT WAIT!

When I created a new page, something seemed off.  There were only a few pages available in the 'choose page layout' list box.  Looks like some article pages and welcome pages were missing.  I went to the mast page gallery and saw that there weren't any pages missing, but there were some pages, like the welcome page with web part zones page layout - which is the page layout used on the default page of the Collaboration Portal site definition - that were not associated to their proper Content Types! Uh - Weird!  How did this happen, and how can we fix it?

Creating new site collections based on the Team Site template proved that we could activate the Publishing Infrastructure Feature without the access denied error, but the page layouts still didn't have the Content Type associated in the Master Page Gallery. Tried this on four site collections.  PublishingPrerequisites, PublishingResources, Navigation, and PublishingLayouts are the Feature Activation Dependencies on the PublishingSite Feature (the Publishing Infrastructure Feature name) and they are all scoped to the site, so why are the page layouts not getting associated with the Content Types?

Creating a new site collection based on the Collaboration Portal site definition worked fine, and the page layouts were associated correctly. Lame.  Must be the order that the site Features are activated.

After going through the Features listed in the onet.xml file for the Collaboration Portal site definition in the order defined, order's NOT the problem.  What is you ask?

So - turns out that the page layouts are tagged as being part of the Master Page Content Type - what's up with that?!?
 

Eidt the page and change the Content Type to the correct one (Page Layout), then set the Associated Content Type.

Check In, Publish a Major Version, and Approve it. Fixed!

Bug...

This seems to have come up a lot for me lately: We have a client who wants to know what it takes to upgrade from WSSv3 to MOSS. What do they need to do to make the MOSS Features available in their current WSS sites?

Having been primarily only working with MOSS, I haven't done much with just WSS and have never run through the upgrade process to MOSS.  There was very little documentation out there other than some forum posts, so today I ran through it for the heck of it and was impressed, but unsurprised, that it was pretty smooth.

To begin, I installed the slipstreamed WSS+SP1 available from Microsoft downloads onto a fresh Windows Server 2003 virtual.  I set it up using SQL 2005 instead of SQL Express, which was a little lazy on my part, because I should have run through what it would take to move the SQL Express stuff over to SQL 2005. Oh well.

I set up my web application with a site collection at the root based on the standard Team Site definition.  This site then got two sub sites.  All three sites had a single Word document in it's Shared Documents doc library.

Then, I installed MOSS+SP1 from MSDN Subscriber Downloads. Here's the steps with some screen shots that I thought were of value:

1) Ran install of MOSS.  Pretty straightforward.  Extracted files, entered key, selected server type, installation of bits and securing of resources, etc, etc...

2) Ran configuration wizard. Says 'This wizard will upgrade SharePoint Products and Technologies'. Config wizard is aware of config db. Runs through nine tasks without hanging on anything for too long, and then completes.

3) Opened Central Admin. On the Operations tab:

When clicked:

Check and click OK:

Completed pretty quick:


One thing to note here - this just enabled the Enterprise SKU Features, I think because I entered an Enterprise key from MSDN, so none of the Standard Features were activated. FYI...

4) Started new services:

5) Created SSP - nothing special here

6) To get Search lined up, I created a Search Center site at the root of the site collection, and changed the site collection search settings to use the new search center I just created:

That was pretty much it. Like I said, impressed, but not surprised.