Sunday, August 24, 2008

SharePoint Designer Considerations

I had this drafted some time ago and never got around to finishing it.

Internally at RDA we had a fantastic discussion on using SharePoint Designer and some best practices around it. First you must understand the primary target audience of SharePoint Designer. It is meant to be a tool for power users who aren't comfortable writing code. If they are not technical and have not resources at who can use Visual Studio, SharePoint Designer is an acceptable choice. However if there are people who know .Net on staff using Visual Studio is more preferable. We have seen a tendency in power users or developers shy away from using Visual Studio because it can become a little complicated to package up and deploy things correctly if you do now know what you are doing. We still recommend that using SharePoint Designer should be kept to a minimum.

A client had some thoughts on SharePoint and was looking for our opinion on it. Below are the questions and paraphrased responses to them.

1) Con: Code stored in database - although there is caching, performance might suffer

Fact is pretty much everything is stored in the SharePoint database, so there really aren't any performance issues. This was a little bit of an issue with SharePoint 2003 but not an issue with SharePoint 2007.

2) Con: No real deployment path with presentation, content, and code mixed together

SharePoint Designer does not facilitate deployment across different environments at all. This is not because the content is all mixed together; it is because SharePoint Designer changes are saved directly to the database. You cannot package things up as a solution or feature and then deploy it to another environment. As well, the changes are not re-useable. Now there are ways of getting around this however they are not supported out of the box and probably not supported by Microsoft.

3) Pro: Good for creative design for styling masterpages

SharePoint Designer is a good tool for making changes to themes/css/master pages and being able to visually see the changes. Remember that the changes to themes/css/master pages can be easily lost when switching between themes or reverting to a definition.

As well, when using SharePoint Designer for master page development you will only be to do this on a site by site basis. Remember that the master page is now customized (unghosted) so the change will have to be applied to each and every site collection which can become painful.

For those who do not know what customizing (unghosting) means, basically there are files that are located on the server where SharePoint server is install (commonly referred to as the 12 hive). Files that can be found there are features, templates, master pages, user controls, etc. When a page is referenced by a user the master page definition on the file server is meshed with content from the database and then displayed. After a master page has been modified by SharePoint Designer, the master page from the 12 hive is copied into the database with the modifications. Then when users reference the SharePoint page, the master page in the database will be meshed with content instead of using the master page on the 12 hive.

It is highly recommended to use Visual Studio for master page development.

4) Pro: Good for prototyping

Yes, SharePoint Designer is a great prototyping tool. It is great for trying to figure out how all the little attributes are working with each other CAML. It is great to use in a development environment.

5) Con: Does not scale well as functional complexity increases

SharePoint Designer does not suffer from scalability challenges; it is just limited in what you can do. It is scoped to doing simple workflows, DataViews, and page layouts, for instance.

6) Pro: Power users can use it

I mentioned this earlier as power users can use this tool to make tactical changes to SharePoint if technical resources are not available to do something in Visual Studio. SharePoint Designer is packaged as part of Office and is the replacement of Microsoft FrontPage.


SharePoint Designer does have its place; however because of the limitations are deployment and re-usability of its solutions, we highly recommend staying with Visual Studio. There are some challenges learning how to deploy web parts from scratch but once you learn the internal workings of how to do these sort of things, you will much better off in the long run.

We also do not recommend giving SharePoint Designer access out to every day users. One of the biggest challenges we have seen with SharePoint migration is heavy Front Page changes which made migration difficult. Do we expect this to be a problem with future SharePoint migrations, hopefully not. However we believe that if you cannot successfully package and deploy something across development, staging and production environments, it should probably not be deployed at all.

Fixing Process Instance XML

A colleague of mine dropped me an email asking about how to resolve a production issues. He has an InfoPath form where a destination user is selected in it. Then when it got to a point in the process where that field needed was used by the destination rule it failed. The reason was because the destination user had left the company and their Active Directory account has been deleted!

He needed to recover the process instance and did not want to tell the business users to start the ticket over again. We considered modifying the process code that was deployed but it was more of a hack. The only other solution was to modify the data in the database. We looked around the database, and were able to find the tables and fields where the XML was stored. However making any sort of changes in this manner would be unsupported by K2 plus we did not want to mess anything up since this is production.

The solution was to write a little snippet of code in a command line application to make a connection out to the server and modify the XML via the API. We went to the Process Overview report, got the process instance number, open the process instance, modified the XML, set it back into the process instance and updated it. The following is Joe Loftus's solution, nice, simple and supported…

using System;
using System.Collections.Generic;
using System.Text;

using SourceCode.Workflow.Client;
using System.Xml;

namespace FixK2InfoPathData
class Program
static void Main(string[] args)

//TODO: Replace Constants with command line args
//TODO: Add third argument which is a path to a repaired xml file to reset the process instance xmlfields value.

//Set to the correct Server Name
const string SERVER_NAME = "SERVER NAME";

//Set to the correct process instance ID
const int PROCESS_INSTANCE = 7;

//Create connection using current credentials (the creds must have access to the process)
Connection cn = new Connection();

//Open Process Instance
ProcessInstance pi = cn.OpenProcessInstance(PROCESS_INSTANCE);

//Get InfoPath xml data
string xoldData = pi.XmlFields[0].Value;

//fix InfoPath xml data
XmlDocument doc = new XmlDocument();
XmlNamespaceManager nsMgr;


//configure Namespace manager
nsMgr = new XmlNamespaceManager(doc.NameTable);
nsMgr.AddNamespace("my", doc.DocumentElement.GetNamespaceOfPrefix("my"));

//Fix the offending elements here
nsMgr).InnerText = "BlackPearlManager";

//Set the repaired InfoPath Xml back to the process instance
pi.XmlFields[0].Value = doc.OuterXml;

//Update the Process Instance