InfoPath - packaging site columns and content types


I do not recommend packaging and deploying content types.  Site columns are fine, but it is best to leave InfoPath content type to SharePoint - since it does quite a few other things during self provisioning and deployment.

WARNING - you have been warned.


A discussion popped up on the InfoPath forums and I took a good stab at it.

Jason Li 

Content Deployment between different environments (InfoPath, SharePoint Designer Workflow, Content Type) in SharePoint 2010
I have read many discussions on this (or similar topic) and still would like to post this again to see if I can get real answers:

  1. I have InfoPath forms.
  2. These forms are published as content types. 
  3. I have reusable SharePoint Designer workflows.  
  4. I have document libraries created to use these content types.
  5. I have security groups.

How do I move these things from DEV to TEST, UAT all the way into PROD. 

As to #3:  GUID is driving me crazy.


Content Type deployment across different farms

The only way I have ever got all the environments to obey my command regarding content types is to use Solution Packages.

  1. Create InfoPath form in DEV, when publishing, use Content Type, and Site Columns.
  2. Once the Content Type and Site Columns are created, package them into a WSP.  From now on, always deploy content type and site columns using WSP.  This forces All the GUIDS to be identical across all farms, which makes everything work nice.  (see below for steps and pictures).
  3. Reusable SharePoint designer workflows can be tied to these content type / site columns, so can document library.
  4. Deploy package to TEST, you can create document libraries with feature as well, or configure them manually.  I deploy InfoPath forms to TEST by publishing from InfoPath to the TEST environment, depending on whether you are doing:
    • Site content type: publish to the destination list - it should automatically pick up the content type since the GUID are the same.  Site columns will match too.
    • Central admin forms - deploy via central admin, this places the form template back in /FormServerTemplates/ on the root site, hook this back using Content Type / advanced / form template in each list.

InfoPath forms always have data connections (since InfoPath can't do anything), you should convert all data connections to connection files hosted relatively on each DEV, TEST, etc. environment, this way you don't need to modify the form template, and depending which environment it's published to, it'll go and find the right sets of data.


Packaging InfoPath Content Type and Site Columns


Packaging site columns and content types are a lot easier now in SharePoint 2010 with VS.NET 2010. 

Grab CKS extension first.

  1. Create an empty SharePoint project on the DEV server.  I've always used Farm Solutions but there's probably no harm trying Sandbox Solutions.
  2. In the Server Explorer, navigate to your SharePoint DEV site.  Expand the nodes and find your Content Type under the root web.  Select Import Content Type to bring this definition into your SharePoint project.

  3. This will import the content type under a feature with a default name Feature 1.  Rename the feature (VS.NET will fix all the related names).

  4. Open the feature and fix the Title as well.  Notice that this feature is Web scoped.

  5. Next, navigate in the Server Explorer to the site columns, and bring in the Site columns that was promoted from InfoPath.

  6. This brings in two additional elements with pretty ugly GUID-names.  Need to tidy this up.

  7. Open the Elements.xml file under the two site columns, and copy the <Field... /> definitions.
    Open the Elements.xml file under the InfoPath content type, and insert the site column definitions above the content type definition.

    (You'll see the content type has FieldRef to the exported columns).

  8. Build the project into a package

  9. Ta-da!


SharePoint Saturday Melbourne update

I had a pleasure of flying down and presenting at the SharePoint Saturday Melbourne event.  Had a great time, met many new people and presented my talk on Custom Rest Services and jQuery AJAX, hope you guys enjoyed it.

Highlights for the presentation were the number of people that put up their hands saying they will try this in their environment - that was very encouraging - it's all fairly simple when you look at the result in small chunks.  Thank you guys.


The links to the PowerPoint presentation and the demo solution are here:


Because I ran out of time (sorry), the bits that I missed were:

  • The 3rd service factory in SharePoint 2010 is for the DataService, allowing you to connect any Entity Framework objects directly into a REST service end-point with almost no code.
  • The 3 service factories are not available in SharePoint 2007, this makes writing services VERY COMPLEX and I don't recommend doing it in 2007.  But you are not out of luck, JavaScript can call the 2007 SOAP services, as long as the correct SOAP envelop is formed before the POST call.  Luckily there are awesome people that has done most of this work:
  • IMPORTANT: I did not explain what the jQuery.ajax's cache: false argument is.  This is very important.  When you call a REST service via a URL, if you do not very the URL/Query string, your browser will return you the same data that it has downloaded previously, and give you a cached copy.  This can be really bad since your service isn't actually called.  jQuery gets around this by appending a random number at the end of the query string, like this:


    This ensures the query string is unique and browser's cache mechanism won't interfere.  HTTP Response code 200 is success.  Rather than 304 which is browser cache.

IANAL but I understand CC

I understand CC, I think, I am not a lawyer.

I was encouraged by @aeoth's rant on twitter to add a license clarification to my blog, since I've always held the (c) which meant "all rights reserved".  Technically that means you need to discuss with me about the terms of copying materials you found on my site, on each individual basis.  Crazy!

So here's a clarification, ta-da!  Hopefully.


Specifically, I ask that:

  1. (-BY) If you are linking or referencing my notes or published code, please provide a link back to either the main site or the permalink.  For blogs and forums these are pretty standard, the only guys that don't do this properly are bots out to plagiarize other people's published work as their own.  For presentations or books, a reference link in the summary slide will be appreciated.
    (-SA) Because I would love to read your improvements on my work, I ask that your content is similarly shared in a open license (openly).  Essentially, if you publish and improve on my work, I would very much like to be able to read it as well.  This applies to published materials: e.g. forums, blogs, PowerPoint presentations, e-books, print.
    Hence, the slightly more restrictive -SA (share alike). 
  2. (-BY) If you are using my published code for production code, the -SA is removed, you may use all code unrestricted with CC-BY, that is, I ask you to link to the permalink in your code comments.  You do not have to share your code back to me.

The spirit of the license is to protect what I feel should be knowledge in the public domain, if you quote someone you should reference them, and if you want to borrow examples or slides from my presentation you should acknowledge it too, but feel free to do so.

At the same time, I don't want to tie anyone down with a restrictive code in their development.  If you need code, found mine, and it solves your problem, leave a link in comments for your colleagues, but you do not have to share your code or change the licensing terms of your code.


That's all, have fun, and I hope the intention is clear.

Finally, a note:

Since I'm not sure if I'm applying a more restrictive license on top of someone else's work by doing this, if I'm quoting your article and for some reason you'd like me to stop, let me know and we can work out what we should do.

SharePoint - Starting Site Workflows Manually

We probably all know that SharePoint 2010 allows you to create a new type of workflow: Site Workflow, these workflows are not bound to a list.  Site workflows are perfect for those one-off jobs that you'd trigger manually.

What's not obvious, to me initially, as well as to many other people, is how does a user actually start one off?

Here's the solution, in one picture, I bet half of you have never noticed this before even though it's always been there from the very beginning.