Merry Christmas

23 12 2009

I want to wish all the readers of my blog and the SharePoint community a Merry Christmas and a Happy New Year!

2010 promises to be an exciting year for SharePoint. With the release of SharePoint Server 2010 and of course the SharePoint Evolution conference in London hosted by Combined Knowledge.

We will be holding regular SharePoint User Group (SUGUK) meetings at Strelley Hall, with the first one on the 14th of January (See the thread here and register if you wish to attend –


New feature – Posting Source Code

11 12 2009

Just when I’d started using the ‘Code Snippet Plugin’ for Windows Live Writer, WordPress have now given us this –

So I thought I would just write a quick post to test it out.

Don’t mind me while I just type some meaningless code with the SharePoint Object Model –

Using (SPSite site = new SPSite(“http://mytest”))
Using (SPWeb web = site.OpenWeb())
SPList list = web.Lists[“MyList”];

*Fingers crossed this looks ok 🙂

Programmatically update InfoPath form Content Type to open in browser

11 12 2009

If you are deploying an InfoPath form to your site as a feature then it is highly likely your form will be installed as a content type. By default however the form will try to open in the InfoPath client if there is one installed on the machine.

You could of course go into the list settings and change this so that new instances open in the browser but this is pain if you are trying to create an automated install/deploy process.

So how can I do this programmatically I hear you ask??

Well it turns out that the SPContentType class has a property called RequireClientRenderingOnNew. This is a boolean value which is by default set to ‘true’.

See the below code snippet on how to change this –

   1: SPContentType cType = web.ContentTypes["My ContentType"];

   2: cType.RequireClientRenderingOnNew = false;

   3: //Update the content type

   4: cType.Update();

The best place to perform this change would probably be in a ‘featurereceiver’.

Hope this helps 🙂


Opening InfoPath form in SharePoint ‘Requested registry access is not allowed’

8 12 2009

This is another gotcha that I’ve run into today – when I went to publish an InfoPath form to my SharePoint site I spotted an error in the design checker ‘Invalid Form Template’. I ignored the error and carried on but when I tried to create a new form based on the template in the document library, I received the following error –

Requested registry access is not allowed. at System.ThrowHelper.ThrowSecurityException(ExceptionResource resource) at Microsoft.Win32.RegistryKey.OpenSubKey(String name, Boolean writable) at Microsoft.Win32.RegistryKey.OpenSubKey(String name) at Microsoft.Win32.Registry.GetValue(String keyName, String valueName, Object defaultValue) at Microsoft.Office.InfoPath.Server.Runtime.FormServer.<>c__DisplayClass1.b__0

I did some research and came accross this blog post from Joel Oleson (@joeloleson) which helped me fix the problem –

The steps I took to fix the error were slightly different from Joel’s (see below) but his blog post helped to point out the registry keys on which the access was failing.

The application pool account for my SharePoint web application was running as ‘Network Service’, I did try and add this account to the ‘Distributed Com Users’ group but this did not fix the problem.

Initially I changed the application pool account for the web application to a domain account and this fixed the problem, then I changed it back to Network Service and gave that built in account read permission on the registry key –


and that also worked! So there are two options in case anyone runs into the same problem.

Hope this helps 🙂

I must remember this when publishing InfoPath forms

8 12 2009

When publishing InfoPath forms to SharePoint ensure that the site you are publishing to has a top level ‘root’ site. E.g. If you are publishing to a virtual path such as “/sites/” and there is no site on the “/” path then the wizard will fail with a ‘URL is not valid’ error!

Silverlight & Cross-Domain Policy

3 12 2009

If you are creating a Silverlight application that makes calls to a web service – either WCF or standard ASP.NET based then you will more than likely need an xml ‘policy’ file that allows cross domain access.

In my case I was calling one of the SharePoint inbuilt web services – lists.asmx from my silverlight application. When I tried to debug the application I received the following error –

An error occurred while trying to make a request to URI ‘http://localhost/sites/mysite/_vti_bin/lists.asmx’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place.

To fix this problem you need to create an xml file called ‘clientaccesspolicy.xml’ with the following content –

<?xml version="1.0" encoding="utf-8"?>
            <allow-from http-request-headers="*">
                <domain uri="*" />
                <resource path="/" include-subpaths="true"/>

This xml file should be placed in the IIS virtual directory where your web service is located. In my case the SharePoint site collection that contained the web service was inside the IIS default website so I put the xml file in ‘C:\Inetpub\wwwroot’.

Once you have created this xml file make sure you do an IISRESET. Your silverlight application should now be calling the web service correctly and not throwing the above exception.

Hope this helps 🙂