Freeware – SharePoint Field Diff And Copy Utility

Just want to the app?

Download here:

Recently at a client I was charged with investigating an application that dealt with incoming / outgoing requests. The data that built up the request objects was being stored as SPListItem’s within their respective SPList objects. After investigation, I was directed to keep the very loosely coupled and inefficient data storage scheme that was actually composed of three lists, rather than well designed metadata, the same. Since I was going to be augmenting the lists, it was necessary for me to have a utility that would allow me to source a list, and copy the relevant SPField objects regardless of base type to a destination list. As a result, I ended up writing my own little utility to automate this task.

The application itself is simple, one form, very few controls.

Start the application:

Give it a URL, get the lists:

This is my source SPList, it has a example fields of all the built-in types:

This is my destination SPList, it has a whole lot of nothing:

Doing the diff, obviously there are a lot of differences:

Then if you begin the copy operation, it will mimic the source list:

Have fun. The source is available on the codeplex site.


Returning The SharePoint Start Workflow Link

Building the “Start Workflow” link is pretty straight forward. I am pretty sure there are better ways to do it, but here is an approach when you have to build the link using a string return. How it works is pretty straightforward. Consuming a SPListItem and SPWorkflowAssociation parameter, the SPListItem exposes the ParentList and ID properties and the SPWorkflowAssociation provides the InstantiationUrl and Id properties. The only field level stuff is I was passing a finish url in the query string (_finalurl in the below). When the link is built, it is cleaned up using the inherent SPHttpUtility.UrlKeyValueEncode method.

private string _finalurl;

public static string QueryStringAppend(string url, string args)
if (string.IsNullOrEmpty(url))
return url;
var num = url.LastIndexOf(“?”);
switch (num)
case -1:
return (string.Format(“{0}?{1}”, url, args));
return num == (url.Length – 1) ? url + args : string.Format(“{0}&{1}”, url, args);

protected string BuildWorkflowStartLink(SPListItem listItem, SPWorkflowAssociation workflowAssociation)
var builder = new StringBuilder();
builder.Append(SPHttpUtility.UrlPathEncode(string.Format(“{0}/{1}”, Web.Url, workflowAssociation.InstantiationUrl), true));
string url = _finalurl ?? Request.QueryString[“Source”];
url = QueryStringAppend(url, string.Format(“{0}={1}”, FinishIdName ?? “ID”, listItem.ID));
if (!string.IsNullOrEmpty(url))
return builder.ToString();



Using FileSystemObjectType.Folder and UnderlyingObjectType in ECMAScript (Client Object Model)

ECMAScript is sorta hit or miss in regards to utility IMHO but I having been involved in a few internal MSFT projects about it so have been using it more and more. Two assets that are significant when working with ECMAScript, specifically item creation, are the FileSystemObjectType enumeration and SP.ListItemCreationInformation.underlyingObjectType property. The FileSystemObjectType enumeration contains the following values:

invalid – the object is invalid.
file – the object is a file.
folder – the object is a folder.
web – the object is a site.

Using these values, you can use the SP.ListItemCreationInformation.underlyingObjectType property to toggle your item creation type, as demonstrated in the below code snippet:

var clientContext = new ClientContext(“http://localhost/”);
var web = clientContext.get_web();
var listCollection = web.get_lists();
var list = listCollection.getByTitle(“TestList”);
var itemCreateInfo = new ListItemCreationInformation();
var listItem= list.addItem(itemCreateInfo);
// Set title and properties
// context.Load(web);
// context.Load(list);