Programmatically Accessing SharePoint List XML Data in C# Code

SharePoint list data can be accessed in custom applications in C# without using SharePoint Object Model or Web Services. The list data can be retrieved as XML using a specific URL to the list (even using a web browser). This is described in this post. This URL can be requested from within the custom code to get the XML. The problem while creating an XMLReader object using the above URL is, it cannot authenticate the user (or application pool identity) into the SharePoint site unless anonymous authentication is enabled in the SharePoint site (which is false in most of the SharePoint implementations). A work around for this problem is to use HTTPWebRequest object to make a request to the list URL and to parse the response stream. Following is an example which takes app pool identity to authenticated into SharePoint site and to get the list data as XML.

String myURL = "<your site URL>/_vti_bin/owssvr.dll?Cmd=Display&List={List GUID}&XMLDATA=TRUE";
HttpWebRequest myRequest = (HttpWebRequest)WebRequest.Create(myURL);
myRequest.Credentials = CredentialCache.DefaultCredentials;
HttpWebResponse myResponse = (HttpWebResponse)myRequest.GetResponse();
Encoding enc = System.Text.Encoding.GetEncoding(0);
StreamReader reader = new StreamReader(myResponse.GetResponseStream(), enc);
string result = reader.ReadToEnd();

The string “result” can be used to create an XML document.

If you are unable to use custom app pools for your web application (older versions of IIS) you can create a NetworkCredentail object to specify custom credentials. In order to do that, replace the line

myRequest.Credentials = CredentialCache.DefaultCredentials;

with the following block.

CredentialCache credCache = new CredentialCache();
credCache.Add(new Uri(myURL), "NTLM", new NetworkCredential("<user name>", "<password>", "<domain>"));
myRequest.Credentials = credCache;

SharePoint List Data as XML

Getting data as XML from a SharePoint List or Library is very helpful when we need to use the data in a custom application (developed using a programming language like C#) or in InfoPath forms. The data from a SharePoint list can be retrieved in XML format by using the following URL:

<your site URL>/_vti_bin/owssvr.dll?Cmd=Display&List={<list GUID>}&XMLDATA=TRUE

You can mention different parameters like “Query”, “FilterField” etc. for specifying columns to be retrieved and for filtering the quantity of data being retrieved. An example for these parameter options is below:

<your site URL>/_vti_bin/owssvr.dll?Cmd=Display&List={<list GUID>}&&XMLDATA=TRUE&Query=<column name>&FilterField1=<column name>&FilterValue1=<value>

The FilterFiled and FilterValue in pairs like FilterField1=<>&FilterValue1=<> and FilterField2=<>&FilterValue2=<> and such.

“System.InvalidProgramException: Common Language Runtime detected an invalid program” while rendering Data View Web Parts

On a busy Tuesday, users of our SharePoint 2010 farm started receiving the following error on a web part page.

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

The web part page was Post.aspx page in a Blog site. We’ve modified XSLT of the web part displaying the post (title and body) in order to change the default blog picture (date view calendar) to poster’s profile picture.

The error message from ULS log was,

Error while executing web part: System.InvalidProgramException: Common Language Runtime detected an invalid program.   
at Execute(XmlQueryRuntime )   
at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer, Boolean closeWriter)   
at System.Xml.Xsl.XmlILCommand.Execute(IXPathNavigable contextDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter results)   
at System.Xml.Xsl.XslCompiledTransform.Transform(IXPathNavigable input, XsltArgumentList arguments, XmlWriter results)   
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.ExecuteTransform(XslCompiledTransform xslCompiledTransform, XsltArgumentList xmlArguments, Boolean bDeferExecuteTransform)   
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)

It looks like a random issue with SharePoint 2010 List View/Data View web parts whose XSLT has been customized. Restarting IIS on the web front end server resolved the issue. Hope Microsoft’s fixed the issue in SP1.

“The Web application at <url> could not be found” – Error with Visual Studio Custom Applications which uses SharePoint 2010 Object Model

Most of us might have seen this error while creating a custom application (console application, Windows application or custom web part) using Visual Studio targeting for SharePoint 2010. It’s not just this specific error but a lot of other weird error messages without any reason. The above error occurs when we create a new SPSite object  using a site URL with following code.

SPSite site = New SPSite (<site URL>);

When we check the web application and site mentioned in <site URL> it exists and can be browsed in browser! Looks like there is no reason for Visual Studio to show this error. But stop yelling at Visual Studio; there is a reason. You haven’t selected the right CPU version for the target application (x64 v/s x86). The reason behind this is, SharePoint 2010 works only on a 64-bit platform but Visual Studio is a 32-bit application. When we open a project in Visual Studio, the default target platform selected is 32-bit. When you compile your custom application, it creates binaries for 32-bit platform which doesn’t work on a 64-bit platform as the way it is expected to be.

So how can we avoid this error? Just change the target platform to x64 in Project Properties > Build section. It’s also recommended to create reference to corresponding assemblies. For example,



Add Only Permission Level in SharePoint 2010

Have you ever had a requirement from your farm users that they need a custom permission level which allows the users/groups to add or submit documents or InfoPath forms into a library but not view or edit them? If you try to create this permission level using SharePoint GUI (Site Permissions > Permission Levels > Add a Permission Level), you will notice that whenever you check the permission “Add Items”, the permission “View Items” will also be checked. There is no way you can check “Add Items” permission alone. But don’t worry, as always, PowerShell is at your help. You can create an add only permission level using the following PowerShell script.

$spweb=Get-SPWeb -Identity "<site url>";
$spRoleDefinition = New-Object Microsoft.SharePoint.SPRoleDefinition;
$spRoleDefinition.Name = "Submit only";
$spRoleDefinition.Description = "Can submit/add forms/files/items into library or list but cannot view/edit them.";
$spRoleDefinition.BasePermissions = "AddListItems, ViewPages, ViewFormPages, Open";

Paste the above script into a text editor and save it into the server with .ps1 extension. From the PowerShell console, execute the ps1 file. You will have the new permission level created in the site collection at <site url>.