Introduction

My current project, due to an extremely tight budget and resource constraints, started out with only half the team: our SharePoint Designers, configurators, and administrators. Their task was to do the information architecture and get the site up as minimally as possible so that the client's content authors can start, well, content authoring.

So first populate the site, and then bring in the developers to build it. Interesting approach. What's more interesting, is that with some careful architectural planning, it's also a very lucrative approach. It allows a large team of people will developments skills that transcend all the layers of SharePoint to crank out a project with an insane timeline without stepping on each other's toes in any way.

In this post, I'd like to discuss this collaboration with two different asset examples: site columns and content types, and page layouts and master pages. The idea is to let your SharePoint Designers loose on a live, vanilla site, so they can quickly build out the information architecture directly in production, and write the page layouts and master page in SharePoint Designer. For those of you who read me often, no, I did not just get diagnosed with multiple personality disorder and started allowing my worst-practice alter ego to post to my blog.

Doing any development whatsoever in production is bad.

Manually configuring your SharePoint environment without the use of a script or features is bad.

And I'll say it: using SharePoint Designer to hack away at a site that will have a lot of custom, code-built functionality is bad.

When I say "bad" above, I don't mean "bad" as in "Don't do it." I say bad because it allows the potential for non-technical users to do things in a static, unrepeatable manner. My team is fortunately full of experienced SharePoint developers who know their tools, and more importantly, their limits. When the non-programmer members of our team created the requirements document and delegated which features were "native creative" and which where custom code, they nailed it; I didn't have to make a single change.

So that allowed them to create the site very quickly (which is the one big benefit to the aforementioned "bad" practices) while we built out our solution infrastructure: TFS, Visual Studio 2010 / SharePoint 2010 project integration, baseline architecture, and, most importantly, deployment package skeleton. Our plan was to achieve these two tasks concurrently as a first step. Step two was then to suck all their assets into Visual Studio, nestle them into the SharePoint 2010 project structures, and write a little code in preparation for a WSP deployment proper.

Site Columns And Content Types

This one is the easier of the two. In order to quickly Visual Studio-inze the site columns and content types, we can use the SharePoint integration into the Server Explorer to connect to the site and import the assets. The only issue with this is that it must be a local site. So I had the client give me a site collection backup, and used PowerShell to restore it to a new one on my box.

Once this was stood up, I was able to connect to it from Visual Studio (with CKS DEV extensions installed). Here's how:

1. From the "View" menu, select "Server Explorer."

   

   Server Explorer

2. Click the "Add SharePoint Connection" button.

   

   Add SharePoint Connection

3. Type in the URL to a local site collection.

   

   Add SharePoint Connection Popup

4. Make sure you have a SharePoint project highlighted in Solution Explorer (that doesn't already have any SharePoint assets imported). Under the new node that's created in Server Explorer, navigate to the "Site Columns" sub node, and then select the Site Column group (rendered as a folder) or a single site column itself. Right click it, and select "Import Site Columns." Visual Studio will add standard SharePoint site column assets with Elements.xml files, all ready to be wrapped into WSP deployment and feature activation.

   

   Import Site Columns

5. Repeat Step #'s 4 and 5 for content types.

   

   Import Content Types

A feature will be created for you if there isn't already one. You can add your own features or import these assets into different SharePoint projects to organize these elements and their deployments however you want. I like to separate the solutions because with all these files things can get cluttered, and putting them into folders (and carefully making sure all relative URL references in the Element.xml files are correct) doesn't seem to work.

One extra task is to make sure things will be deployed in the correct order. Since content types depend on site columns, site columns need to be activated first. Also, if you have content type inheritance, base content types need to be deployed before any of their children (otherwise you'll get an error in Visual Studio upon a CKS "deploy with activation" operation saying that the parent content type doesn't exist). You might have to manually edit the Feature.xml file for your feature, and manipulate the XML so that the order is correct.

Here's how to do that:

1. Expand the feature, and double click the "Feature1.feature" node in Solution Explorer.
2. In the Feature Designer, click "Manifest."
3. Plus out "Edit Options."
4. Click "Overwrite generated XML and edit manifest in the XML Editor."
5. Click "Yes" on the overly-cautious pop up.

Now we can get at the XML:

1. Click "Edit manifest in the XML editor." This actually disables the designer for this feature.
2. Update your ElementManifest nodes so that normal site columns are first, then lookup site columns, then base content types, and finally derived content types. Save the finally normally. As you could tell in the above screen shot, you can revert back to the generated order by repeating the proceeding procedure and clicking "Discard manifest changes and re-enable the designer" and then "Yes" on the pop up window.

And that's it; Visual Studio now "owns" the site columns and content types. It's best if you can blow away the site collection before deploying from a Visual Studio-packaged WSP, or at least delete all the assets you're about to push. If you can't, the deployment still works; updates are performed instead of inserts. I have seen columns get duplicated in inherited content types down in lists and libraries, and other weirdness when we had to deploy over existing content. In this project, we fortunately had the luxury of blasting all existing content, so I didn't have to explore the update scenario further; I would be shocked if you couldn't get it to work somehow.

Page Layouts and Master Page

The other integration point is for our pages. This one is much more interesting; not only do we get to write some code, but it also solves the greater problem of page creation workflow between SharePoint designers and developers. Let's delve into that first, and look at the feature receiver that does the work second. This paradigm is really the crux of this post.

Like I said, making changes in production is bad. In addition to the issues I pointed out before, it makes tasks like the ramping up of new project resources or provisioning development and staging environments very difficult and time consuming. Having a dev environment that doesn't match prod is a really easy way to introduce regression bugs into your build. Even if you've gone through a checklist of all the manual tweaks needed to stand the site up proper, it's easy to miss something. This is why we need Visual Studio-generated WSP's to "own" all facets of deployment.

That said, making changes in production is fast, and given the skillsets of certain members of the team and timeline or resource constraints of the project, it just might be the best way to go. This is especially true for the first iteration of a project; I have no problem treating production as a development server before the site goes live. You can simply get away with being sloppier. But once it's pushed, we need to exercise much deployment diligence if updates are to be applied seamlessly.

So here's the procedure for integrating page layouts (master pages follow the same rules, so I'll omit them except when they differ) created in SharePoint Designer into Visual Studio. With these, there's no issue with creates verses updates; even if an instance of a page based off one of these layouts exists, we can totally run this code to update the layout without breaking anything.

First things first: we need a page. Create a new ASPX page in Visual Studio (with code behind) and place it somewhere under your mapped SharePoint Layouts folder. It's fastest to create a new SharePoint Application Page and change the base class to PublishingLayoutPage, since ASP.NET templates aren't available in SharePoint projects. You might have to add a reference to Microsoft.SharePoint.Publishing.

Copy and paste the HTML from SharePoint Designer (or wherever) into the ASPX file.

At the top of the page, replace the @Page directive with the following two lines of markup (of course using your class names):

In Line #1, we take advantage of the Visual Studio / SharePoint 2010 integration feature that tokenizes our FQNs. This is what allows us, in Line #2, to not have to fully-qualify the class name for the value of the "Inherits" attribute (like SharePoint otherwise normally requires).

Repeat this for all page layouts, and your master page. For the master page, you of course use an @Master directive instead of @Page, and omit the "MasterPageFile" attribute in the HTML. And in the code behind, you inherit from the plain old ASP.NET MasterPage class. However, since all these pages will either live in the master page gallery or within _layouts in 14, they can all follow the same procedure.

Now that our layouts are in Visual Studio, we need to prepare them for WSP deployment. First, create a module for each file. Here's what a sample Elements.xml would look like:

These modules allow us to deploy all new page layouts to the 14 folder and ghost them in the master page gallery. Existing layouts created with SharePoint Designer, however, explicitly live in the content database, and are represented by fully fledged SPFile objects in the gallery. But by giving these a module as well, we have the flexibility to _layouts-deploy them to 14 should the client, in an ideal "version one" phase, allow us to blow the page layouts away.

But what about overwriting existing layouts that already live in the gallery, and can't be moved or deleted and re-created by Visual Studio? This is where the code comes in. We are going to create a feature with a receiver that analyzes the modules in our WSP, and for all pages, contains logic to decide how to update them (again, without disrupting any existing pages provisioned from them). Let's look at the code:

Line #19 is our entry point to reflectively iterate our feature's Element.xml files. Line #'s 27 - 33, for each module its files, we parse the XML, allowing us to get a URL to the file, as well as a path to where it exists in _layouts. The big money is in Line #34, which switches the CustomizedPageStatus property of the SPFile, and determines what we have to do to properly update the content of the file without breaking any references to any pages. The comments on Line #'s 36, 41, and 45 describe what each value of the enumeration implies. Finally, Line #54 starts the "UpdateFileBitsInDatabase" method. Basically, we check out the file in the gallery, (using some fancy extension methods we have) read the bits from the corresponding page in _layouts, write them to the file, and using more extensions methods, check in, publish, and finlly approve the page layout. (The extension methods do things like only approving the file if moderation is turned on for the document library, etc.)

Now that Visual Studio owns the deployment of our pages as well, we need a little red tape. If the SharePoint Designers update anything live on the site, the onus is on them to provide us with the HTML. Copy-and-paste it into the corresponding page in Visual Studio, fix up the @Page or @Master directive as above, and it will be deployed with the next WSP push. This means that the changes will be overwritten; if they forget to give us their markup, their updates will be lost.

Updates to site columns and content types are a little hairier. There's the content type inheritance duplicate column problem I noted earlier, as well as the fact that we'd need to restore another backup of the site collection to our development environment in order to suck in the new assets. This is time consuming, and a practice we only use when necessary; the standard protocol is that after a certain time in the content authoring phase, (which is concurrent with initial development) the site structure is frozen. Any changes moving forward must have originated in Visual Studio and implemented with feature receiver code that will ensure proper asset updates.

That's it! This is a great story for hybrid SharePoint designer / developer teams. With the correct architecture and deployment procedures in place, you can allow everyone to use their skillsets and toolsets to deliver a site not only extremely quickly, but also compliant with best practices. Have fun collaborating!