One of the use cases where we use the SharePoint.DesignFactory.ContentFiles tooling is in building SharePoint Publishing (WCM) solutions for SharePoint 2007, SharePoint 2010 and Office365.
Publishing solutions are often solutions that have one instance, the publishing site (possibly with subsites), that in most cases need to go through DTAP.
If you dissect a publishing site, in most case you have the following findings:
- The publishing site spans a site collection
- The branding of the site is specified in the root site, because:
- Master pages live in the root site (/_catalogs/masterpage)
- Page layouts live in the root site (/_catalogs/masterpage)
- The style library lives in the root site ( /Style Library) and contains images, css, javascript, xslt transformations for your CQWP’s, …
- Preconfigured web parts live in the root site (/_catalogs/wp)
- The root site and subsites contains a document library called Pages (or your language-specific version of it) containing publishing pages using the page layouts and master pages
- The site collection contains content types, fields and lists
When using the SharePoint.DesignFactory.ContentFiles tooling it is very easy to create, test, package and deploy the artifacts that can be uploaded to the SharePoint content database. This can be done in a fast and simple way without the need to create and deploy WSP packages. If we look at the above list of artifacts we can use SharePoint.DesignFactory.ContentFiles for master pages, page layouts, the style library, web part configurations, and initial publishing pages (these are normally made through the SharePoint web UI).
Some artifacts like content types, fields and lists in the above list can NOT be handled by SharePoint.DesignFactory.ContentFiles, because they can’t be uploaded to the SharePoint content database. The good thing is that these artifacts are the artifacts that don’t change that much in the development of a SharePoint Publishing solution. There are however multiple ways to create these artifacts:
- Use paper script: create them manually in each of the environments based on documentation
- Automate the creation of the artifacts using (PowerShell) script
- Develop a WSP package to create these artifacts
I’m not a big fan of the third option (see my blog post Thoughts on building deployable and updatable SharePoint solutions). It is a lot of work to create content types, fields and list definitions using all kind of XML files, and it is not allowed to modify these artifacts when in use. I know… SharePoint 2010 has some content type upgrade possibilities, but I think it is just too cumbersome.
The first option has the problem that content types and fields get ID’s, and that these ID’s must be used by the metadata on for example page layouts. No problem for SharePoint.DesignFactory.ContentFiles, because it supports deploy-time resolving of these ID’s using PowerShell. For example consider the following metadata definition for the page layout contactpage-wcm.aspx.properties.ps1:
Metadata page layout
- # This script must return a hashtable @{ name=value; ... } of field name-value pairs
- # for the content file that this script applies to.
- # On deployment to SharePoint, these values are written as fields in the corresponding list item (if any)
- # Note that fields must exist; they can be updated but not created or deleted.
- # This script is called right after the file is deployed to SharePoint.
-
- # You can use the script parameters and arbitrary PowerShell code to interact with SharePoint.
- # e.g. to calculate properties and values at deployment time.
-
- param([string]$SourcePath, [string]$RelativeUrl, $Context)
- @{
- "ContentTypeId" = $Context.GetContentTypeID('GeneralPage');
- "MasterPageDescription" = "Cloud Aviator Contact pagelayout (wcm - don't use)";
- "PublishingHidden" = "1";
- "PublishingAssociatedContentType" = $Context.GetAssociatedContentTypeInfo('GeneralPage')
- }
The PowerShell functions GetContentTypeID and GetAssociatedContentTypeInfo can at deploy-time resolve the required information from the server we are deploying to.
I personally prefer the second option: automate creation through PowerShell, because there are PowerShell scripts available to export content types and fields.
An example project structure for a typical SharePoint WCM site looks like:
Note that this project uses DualLayout.
So if you build Publishing sites using SharePoint, checkout out the completely free SharePoint.DesignFactory.ContentFiles tooling and start flying!
The SharePoint.DesignFactory.ContentFiles tooling can be used to develop, test, package and deploy SharePoint files and metadata that can be uploaded to the SharePoint content database. Use this tooling for developing and packaging your master pages, page layouts, style library files, web part configurations and any file you can think of that can be uploaded to the SharePoint content database. Works on SharePoint 2007 (on SharePoint server), SharePoint 2010 (on SharePoint server or remote) and Office365 (remote).
Installation is simple. In this post I will show the steps required to install the SharePoint.DesignFactory.ContentFiles on a Visual studio project.
- Fire-up Visual Studio 2010 and create a new project (File > New > Project…)
- Under Installed Templates select Visual C# > Web
- Select the .Net Framework 3.5, then select the ASP.NET Web Application project
- Note that the resulting project contains all kind of artifacts that are not relevant in the context of a SharePoint.DesignFactory.ContentFiles project:
- If NuGet is not installed yet on your Visual Studio (Tools > Library Package Manager is missing), start the Visual Studio Extension Manager (Tools > Extension Manager…). In the Extension Manager window select the Online Gallery at the left and search for NuGet. Select the NuGet Package Manager and press the Download button to install NuGet. Preferably use NuGet 1.7 or up to use all features available in the SharePoint.DesignFactory.ContentFiles NuGet package.
- Right-click on the just created Web Application project and in the context menu select Manage NuGet Packages….
- In the Manage NuGet Packages window select Online at the left and search for SharePoint.DesignFactory.ContentFiles. Select the SharePoint.DesignFactory.ContentFiles package and press the Install button.
- After installation where a lot of project manipulation magic happens the following message appears. An assembly is installed in the solution folder containing Visual studio Solution Explorer context menu actions that makes working with SharePoint.DesignFactory.ContentFiles even easier. This assembly is magically loaded by a Visual Studio extension called Managed Menu Extension (MME). Although this extension is not required and it is perfectly possible to work without the additional context menu actions, it is advised to install the Managed Menu Extensions (explained in the next step).
- Install the Managed Menu Extensions (MME) through the Extension Manager (Tools > Extension Manager…). Select Online Gallery and search for MME.
- Visual studio requires a restart for the Managed Menu Extensions to work and the context menu extension for SharePoint.DesignFactory.ContentFiles to work. Close Visual Studio, and reopen Visual Studio with our new solution in one of two ways (First starting Visual Studio and then loading the solution does not load the menu extensions):
- By starting the solution through the start menu
- By double-clicking the solution file in the explorer
- We are done with installation! The project is cleaned up, all unwanted files are removed. You are presented with a readme file explaining some things about the SharePoint.DesignFactory.ContentFiles tooling.
In a next blog post I will give a tour through a SharePoint.DesignFactory.ContentFiles enabled Visual Studio project.
Wouldn’t it be great to edit your SharePoint 2007/2010/Office365 content files like master pages, page layouts, web part files, style library files etc. etc. in Visual Studio, use intellisense, source control and the XSLT debugger, but without the overhead of creating complex xml files, manifest files and WSP packages? Wouldn’t it be great if you could package those file and deploy them through Dev, Test, Acceptation and Production without WSP packages? Now you can!
Create an ASP.NET Web Application Project, add the SharePoint.DesignFactory.ContentFiles NuGet package and start building!
See the included documentation for more information. More information will follow on this blog!