Corey Roth [MVP] : LINQ to XML

A simple way to programmatically create SharePoint security groups

CoreyRoth — Mon, 08 Mar 2010 17:12:50 GMT

When it comes to SharePoint deployments, I try to automate everything I can. I don’t like manual steps especially when it comes to setting up security. A common task when deploying any sites is setting up security in some manner. Today I am going to cover how to easily store definitions your SharePoint security groups in an XML file. We’ll use LINQ to XML to make reading the file a breeze, and then we’ll use the SharePoint object model to create the groups and add users (or AD groups). I’ve blogged on how to create a group before, but we’re going to take this a step further by giving you code that you can easily add to a feature receiver or console application. First let’s take a look at the XML file we’re going to use.

<?xml version="1.0" encoding="utf-8" ?>
<Groups>
  <Group Name="My Custom Read Group" Owner="SHAREPOINT\GroupOwner" Description="Readonly Permission Group" PermissionLevel="Read">
    <User Name="SHAREPOINT\TestUser1" />
    <User Name="SHAREPOINT\TestGroup1" />
    <User Name="SHAREPOINT\TestGroup2" />
  </Group>
  <Group Name="My Custom Contributors Group" Owner="SHAREPOINT\GroupOwner" Description="Contributors Permission Group" PermissionLevel="Contribute">
    <User Name="SHAREPOINT\TestGroup3" />
  </Group>
</Groups>

In this file, I am defining two SharePoint groups. One that will have read access and one that will have contribute access. I store the required information needed by the Add method on the SPGroupCollection object. I then have one or more User elements with the name of my Active Directory user or group. I tried to keep my XML schema pretty simple. You can customize it obviously how you want, you would just have to alter your LINQ queries.

Let’s take a look at the code we need to make this happen. I won’t go into as much detail of the object model since I went into it pretty well on my last post. We’ll just focus on how we use LINQ to XML to read the information we need and then have it create our groups. My method is called CreateGroups and it takes an SPWeb object and a string with the filename of the XML document.

private void CreateGroups(SPWeb currentSite, string groupsFilename)
{
    // get the xml document from the feature folder
    XDocument groupsXml = XDocument.Load(groupsFilename);
 
    // create a new anoynmous type with the group data
    var groups = from sharePointGroup in groupsXml.Root.Elements("Group")
                select new
                {
                    Name = sharePointGroup.Attribute("Name").Value,
                    Owner = sharePointGroup.Attributes("Owner").Any() ? sharePointGroup.Attribute("Owner").Value : null,
                    Description = sharePointGroup.Attributes("Description").Any() ? sharePointGroup.Attribute("Description").Value : string.Empty,
                    PermissionLevel = sharePointGroup.Attributes("PermissionLevel").Any() ? sharePointGroup.Attribute("PermissionLevel").Value : null,
                    Users = sharePointGroup.Elements("User").Any() ? sharePointGroup.Elements("User") : null
                };
 
    // iterate through the groups and create the groups
    foreach (var sharePointGroup in groups)
    {
        // only create the group if it does not exist
        if (!ContainsGroup(currentSite.SiteGroups, sharePointGroup.Name))
        {
            // add the owner to the web site users
            currentSite.EnsureUser(sharePointGroup.Owner);
 
            // add the group
            currentSite.SiteGroups.Add(sharePointGroup.Name, currentSite.SiteUsers[sharePointGroup.Owner],
                currentSite.SiteUsers[sharePointGroup.Owner], sharePointGroup.Description);
        }
 
        // add the users to the group
        AddUsersToGroup(sharePointGroup.Name, sharePointGroup.Users, currentSite, sharePointGroup.PermissionLevel);
    }
}

This seems like kind of a big method at first, but it’s really not that bad. To keep things simple, I haven’t included any exception handling code. We are really just querying the XML document, iterating through each group element inside of it, creating the groups, and then adding the users to the group. The first line of code just creates an XDocument object. We then construct a LINQ to XML query. What we want is to return data from each Group element in the document. The Add method doesn’t like nulls, so we check for them and use string.Empty if the value does not exist in the file. The one case where I don’t do this is for the Name of the group. If that is not present, I would rather the process throw an exception. As for the Users assigned to the group, I grab all of them and add them to our anonymous type like this.

Users = sharePointGroup.Elements("User").Any() ? sharePointGroup.Elements("User") : null

This gives us an IEnumerable<XElement> that we can pass to a method later to add each Active Directory user (or group) to the SharePoint group. Once we execute the query, we iterate through each group element. The first thing we have to do is make sure that the group does not exist. Of course there is no way to do that other than using the try/catch technique. I will usually wrap this in an extension method, but for today’s purpose, we’ll just call a method to check.

private bool ContainsGroup(SPGroupCollection groupCollection, string index)
{
    try
    {
        SPGroup testGroup = groupCollection[index];
        return true;
    }
    catch (SPException e)
    {
        return false;
    }
}

Lame I know. I’m so happy there are ways to get around this in SharePoint 2010. Then this starts to look like code from the previous post. We call .EnsureUser to make sure the domain account of the group owner is registered with the site. We then just call the Add method with the Name, Owner, default user, and description. Again there is more info on the previous post about that method call. Assuming the group is created, we can then add the users to the group. We call a new method AddUsersToGroup which takes the groupName, the users element, an SPWeb, and the permission level.

The first thing we do is query the names of the Active Directory users (or groups). Here we are just grabbing it from the Name attribute of the User element. I probably could have condensed this query, but at least it’s easy to read. We then add each user (or group) from the User elements to the group. If you are curious about the empty parameters, take a look at the previous post. If you are going to run into an exception, it’s going to be here. If the group failed to be created or if the user does not exist (i.e.: you typed it in the XML file wrong), this line will throw an exception.

private void AddUsersToGroup(string groupName, IEnumerable<XElement> users, SPWeb currentSite)
{
    // select the username from the xml document
    var userList = from user in users
                   select new
                   {
                       Name = user.Attribute("Name").Value
                   };
 
    // add the users to the sharepoint group
    foreach (var user in userList)
    {
        currentSite.SiteGroups[groupName].AddUser(user.Name, string.Empty, user.Name, string.Empty);
    }
}

Now, we’re almost done. The last thing we need to do is set the permission level on the group. This is where we specify whether the group has readonly, contribute, full control, etc access to the site. Be sure and get the name on the permission level right otherwise you will get an exception. I’ve also blogged about how to assign permission levels before. Today’s post is really just a great practical use of putting together the things I have posted on before.

private void SetRoleDefinitionBinding(string groupName, SPWeb currentSite, string permissionLevel)
{
    // add the read role definition to the site group
    SPRoleAssignment roleAssignment = new SPRoleAssignment(currentSite.SiteGroups[groupName]);
    roleAssignment.RoleDefinitionBindings.Add(currentSite.RoleDefinitions[permissionLevel]);
    currentSite.RoleAssignments.Add(roleAssignment);
    currentSite.Update();
}

Effectively you create a new SPRoleAssignment by passing it a SPGroup object. You then add a binding using the existing RoleDefinitions on the site. You then add the assignment to the site and of course call .Update() so things get saved.

That’s really all there is to it. This is a great use of combining information from my previous posts into something that you can use everyday to set security on your sites. How you execute this code is up to you. I’ve used it in a feature receiver and in a console application before. Setting up security through the UI is very slow and painful. Once you create it on one server, there is no way to move it to another server and that’s not a lot of fun. This should help you with that and eliminate those nasty manual steps in your deployment process.

Linq to XML and Deleting Lists on Feature Deactivation

CoreyRoth — Thu, 24 Sep 2009 20:04:04 GMT

A few months ago, I discussed how to use LINQ to XML to parse your elements.xml file to delete any files that you may have deployed on feature activation. Today I have decided to reuse this concept to delete any lists that I have created when I deactivate a feature? Now you may ask, “why would I want to delete a list when a feature is deactivated? I’ll lose all of my data in that list!” My answer is: Yes, of course you will, but sometimes when building a feature to deploy a list(s), you want to delete the list each time before you deploy a new version of it. During development this is a huge time saver. Right now, I am working on a feature that deploys four document libraries. This means I have to manually delete each one. That is a huge waste of time, but what is nice is that we can reuse the concept above with LINQ to XML and delete lists instead.

The code is quite similar. Have a look. We first, write some code to get the path to the elements.xml file. This code snippet assumes, it is always named Elements.xml. Maybe in the future, I will have it look in the feature.xml file, get all of the ElementManifest definitions and then delete whatever it finds in each file. For now though, we assume, you can change the path as needed.

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
{
    using (SPWeb currentSite = (SPWeb)properties.Feature.Parent)
    {
        string elementsPath = string.Format(@"{0}\FEATURES\{1}\Elements.xml", SPUtility.GetGenericSetupPath("Template"), properties.Definition.DisplayName);
        DeleteLists(currentSite, elementsPath);
    }
}

From here, it passes a reference to the current SPWeb and the path to the XML document. The path to the elements.xml file is used to populate an XDocument which we can then query with LINQ to XML.

private void DeleteLists(SPWeb currentSite, string elementsPath)
{
    try
    {
        XDocument elementsXml = XDocument.Load(elementsPath);
        XNamespace sharePointNamespace = "http://schemas.microsoft.com/sharepoint/";
 
        // get each URL to each list
        var listInstances = from module in elementsXml.Root.Elements(sharePointNamespace + "ListInstance")
                        select new
                        {
                            ListUrl = (module.Attributes("Url").Any()) ? module.Attribute("Url").Value : null,
                        };
 
        // iterate through each list and delete it
        foreach (var listInstance in listInstances)
        {
            try
            {
                SPList currentList = currentSite.GetList(string.Format("{0}/{1}", currentSite.Url, listInstance.ListUrl));
                currentList.Delete();
            }
            catch (System.IO.FileNotFoundException e)
            {
                // this exception is thrown if the list does not exist
            }
        }
 
        // update the site
        currentSite.Update();
    }
    catch
    {
    }
}

This code is quite similar to that used in my other post, however instead of looking for Module elements we are looking for ListInstance elements. It creates a list of those Urls to each list and iterates through them. For each list it finds, it deletes the list. I’ve written code in the past to manually delete lists, I create by name. That works fine, but the name of each list has to be maintained. Now, I just attach this to any feature I am working on and it deletes any list (or lists) that I throw at it. More than likely this isn’t something you want once you go to production, but it will save you a ton of time during development.

Using LINQ to XML to access the data of a form saved to a form library in a workflow

CoreyRoth — Wed, 06 May 2009 21:40:37 GMT

As I have mention in the past LINQ to XML is a great way to manipulate the XML data out of an InfoPath form. I thought I would show how you can also use the same technique to work with the data of a form saved to a form library which launches a workflow (although you could apply this technique to the association or task forms as well). The first thing we need to do is get the XML of the InfoPath initiation form, before we can work with it.

For the purpose of my example, my OnWorkflowActivated activity writes to a public SPWorkflowActivationProperties property called workflowProperties. In my Invoked event handling method of my OnWorkflowActivated activity, we use the Item object on my workflowProperties to open the file and get the XML. You can then use the File object along with OpenBinary() to get the raw bytes of the XML.

byte[] xmlBytes = workflowProperties.Item.File.OpenBinary();

You can then takes those bytes and read them into a regular string.

string xmlString = System.Text.Encoding.UTF8.GetString(xmlBytes);
if (xmlString[0] == (char)0xfeff)
    xmlString = xmlString.Substring(1);

If you are curious about the 0xfeff business that is used to deal with the byte-order mark character in Unicode. I picked up this trick from another post somewhere, but I can’t remember where currently.

Now we need to get the XML string into an XDocument class so that we can query it and manipulate it. Since we have a string, we will need to create a StringReader to read it.

XDocument documentsXml = XDocument.Load(new System.IO.StringReader(xmlString));

If you wanted to work with the Association form instead of the form that started the workflow, you would use a line like the following. The InitiationData property of the SPWorkflowActivationProperties object provides XML that can be loaded into the XDocument class.

XDocument documentsXml = XDocument.Load(workflowProperties.InitiationData);

InfoPath documents always have a namespace defined for my so we need to use the XNamespace object for any future references inside the InfoPath form.

XNamespace documentNamespace = "http://schemas.microsoft.com/office/infopath/2003/myXSD/2098-05-03T16:48:38";

At this point you can start using LINQ to XML to get the data you need out of the InfoPath form. For example, if I had a field called my:FirstName at the root of the document. I could use something like the following to get the value.

string firstName = documentsXml.Root.Element(documentNamespace + "FirstName").Value;

If you are working with other data types, you can always cast it like this.

int customerId = int.Parse(documentsXml.Root.Element(documentNamespace + "CustomerId").Value);

In my example from last week, you saw how you could use LINQ to XML to iterate through a repeating table. As another example to iterate through a repeating table called Items with an element of Item, you could do something like the following:

var items = from item in documentsXml.Root.Element("Items").Elements("Item")
            select item;
 
foreach (var item in items)
{
    Console.WriteLine(item.Element("Field1").Value);
    Console.WriteLine(item.Element("Field2").Value);
}

In this case, I use LINQ to return an IEnumberable<XElement> representing each repeating item. I can then use this in a foreach loop to print out the results. Yes I know you wouldn’t use Console.Writeline in a workflow, but you get the point here. LINQ to XML really offers a lot of flexibility to manipulate the XML data inside a form. Hopefully, it will make your experience with InfoPath and workflow a better one.

Code samples from my short talk about LINQ to XML

CoreyRoth — Wed, 29 Apr 2009 15:02:00 GMT

Today, I had the opportunity to give a short introduction on how to do some basic queries on XML documents with LINQ to XML. In the talk, I talked about how to create anonymous types from your XML document so that you can work with strong types. I also showed some uses some of the classes, methods, and properties, they would use most when working with LINQ to XML.

I also discussed how LINQ to XML can be used to make working with repeating tables in InfoPath easier. Consider the following XML of an InfoPath form. We have a repeating table called RepeatingTable and in the table there is element called Item.

<?xml version="1.0" encoding="utf-8"?>
<my:myFields xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2008-12-30T15:48:37"
             xmlns:xd="http://schemas.microsoft.com/office/infopath/2003" xml:lang="en-US">
  <my:RepeatingTable>
    <my:Item>
      <my:Name>Polo Shirt</my:Name>
      <my:Color>26134</my:Color>
      <my:Price>19.99</my:Price>
    </my:Item>
    <my:Item>
      <my:Name>Jeans</my:Name>
      <my:Color>01823</my:Color>
      <my:Price>29.99</my:Price>
    </my:Item>
  </my:RepeatingTable>
  <my:Id>83123</my:Id>
</my:myFields>

If you needed to work with this repeating table when the InfoPath form was loaded again, you could use code like the following. You could also apply a similar technique to work with this data inside a workflow.

// use the MainDataSource to read the XML of the InfoPath Form
XDocument infoPathDocument = XDocument.Load(new System.IO.StringReader(MainDataSource.CreateNavigator().OuterXml));
// required to access my: namespace
XNamespace myNamespace = "http://schemas.microsoft.com/office/infopath/2003/myXSD/2008-12-30T15:48:37";
// use descendants node to find any element with the name Item in the tree
var items = from item in infoPathDocument.Descendants(myNamespace + "Item")
            select new
            {
                Name = item.Element(myNamespace + "Name").Value,
                Color = item.Element(myNamespace + "Color").Value,
                Price = item.Element(myNamespace + "Price").Value
            };
foreach (var item in items)
{
    // do something
}

In the code above, I use the CreateNavigator method of the MainDataSource as usual when working with an InfoPath form and I use a StringReader to load it into an XDocument. Since InfoPath form’s always use the my namespace it is necessary to declare it using the XNamespace object and use it before referring to any element or attribute in the document. In the example above, I create a new anonymous type with the Name, Color, and Price and then I can use a foreach loop to iterate through the items.

I have attached the code for the example above as well as the other examples I mentioned in the talk to this post. Please, let me know if you have any questions.

Follow me on twitter.

Using a namespace with LINQ to XML

CoreyRoth — Fri, 29 Aug 2008 20:29:12 GMT

If you are using LINQ to XML, sooner or later, you will need to work with XML documents that don't use the namespace. For example, you might be working with the XML from an InfoPath form and you want to get the value of a particular element. InfoPath uses the my namespace, and you can't just specify it directly in the string (i.e.: Root.Elements("my:Group2") will not work). To resolve this, we create a XNamespace object and pass it the URI to the namespace.

XNamespace myNamespace = "http://schemas.microsoft.com/office/infopath/2003/myXSD/2008-02-15T09:18:32";

Once you declare the XNamespace, it's just a matter of including it before any elements or attributes you might use.

var transmittalCollection = from transmittalNode in formDocument.Root.Descendants(myNamespace + "group2")
                            select new Transmittal
                            {
                                MyNode = transmittalNode.Elements(myNamespace + "MyNode").Any() ? transmittalNode.Element(myNamespace + "MyNode").Value : null,
                            };

That's all there is to it. I have found it very useful when I want to query data out of an InfoPath form. I just submit the data to a service and then I use LINQ to XML to parse out the values I need. It is much easier for me than using XPath.

NEW! Web Part for Wildcard Search in Enterprise Search

CoreyRoth — Mon, 09 Jun 2008 13:28:15 GMT

I have had countless people tell me that they want to be able to do wildcard search in MOSS Enterprise Search using the existing Search Center site templates. The Search Center site template uses keyword query syntax which does not support wildcards. To get wildcards you need to use a full text SQL query. Until now the only solutions to getting wildcard search was either use Ontolica's Wildcard Search or write your own search page. Neither option has ever been appealing to me. Ontolica replaces the entire search center and provides an extra layer of abstraction to your managed properties. I didn't want to write my own search page because the search center already produces great looking results and it would be a lot of effort to reinvent everything on the search page. The reason why you would have had to write your own search page is that you could not get access via conventional means to the objects to change the query.

This is why I finally decided to take matters into my own hand. I really just wanted to just inherit from CoreResultsWebPart, change out the keyword query with a FullTextSqlQuery and call it good. Anyone who may have looked at this before knows it is not that simple. The class that does all the work SearchResultsHiddenObject is marked internal. Right now this seems an impossible task unless you bend the rules a little. That's right. I decided I am going to break OO rules and use reflection to get to the properties I needed. Some people say you should never do this and that its a hack. I agree to some extent, but when you are programming against an API and the provider of said API doesn't give you the tools you need to do your job, sometimes you have to bend the rules. Let's face it. Microsoft should have given us this support out of the box and at the minimum should have allowed us to change the query that the CoreResultsWebPart executes through the API. They did neither so here we are.

So how does the code work? Well, CoreResultsWebPart happens to be the one class in all of the Enterprise Search controls that isn't marked sealed. That is good news. Through the use of Reflector, I discovered the method I need to inherit from is SetPropertiesOnHiddenObject. Microsoft was even nice enough to mark this method as virtual for me. I then got access to the type and then used the base type to get a FieldInfo object for the private field srho (which is the SearchResultsHiddenObject).

// get the type of the current object
Type coreResultsWebPartType = this.GetType();
 
// get the private field containing the searchResultsHiddenObject
FieldInfo searchResultsHiddenObjectField = coreResultsWebPartType.BaseType.GetField("srho", BindingFlags.NonPublic | BindingFlags.Instance);

Once, I got access to the hidden object, I read the value of the KeywordQuery property to get what the user searched for. I then had to set this value to null, because I was replacing the keyword query with a FullTextSqlQuery.

// get the actual internal srho object attached to CoreResultsWebPart
object searchResultsHiddenObject = searchResultsHiddenObjectField.GetValue(this);
 
// get the type of the srho
Type searchResultsHiddenObjecType = searchResultsHiddenObject.GetType();
 
// get the keyword query property
PropertyInfo keywordQueryProperty = searchResultsHiddenObjecType.GetProperty("KeywordQuery", BindingFlags.Instance | BindingFlags.Public);
 
// read what the user searched for
string keywordQuery = (string)keywordQueryProperty.GetValue(searchResultsHiddenObject, null);
 
// set the keywordProperty to null so we can change it to a fullTextQuery
keywordQueryProperty.SetValue(searchResultsHiddenObject, null, null);

It was then just a matter of forming a new SQL query string (check the code on how I did that), and setting some additional fields _IsFullTextQuerySetFromForm and m_bIsKeywordQuery.

 
// get the fullTextQuery field
PropertyInfo fullTextQueryProperty = searchResultsHiddenObjecType.GetProperty("FullTextQuery", BindingFlags.Instance | BindingFlags.Public);
 
// create a new query and set it
string fullTextQueryString = GetFullTextQuery(keywordQuery, keywordsAsQuery);
fullTextQueryProperty.SetValue(searchResultsHiddenObject, fullTextQueryString, null);
 
// this field needs to be set to true to use a full text query
FieldInfo fullTextQuerySetField = searchResultsHiddenObjecType.GetField("_IsFullTextQuerySetFromForm", BindingFlags.NonPublic | BindingFlags.Instance);
fullTextQuerySetField.SetValue(searchResultsHiddenObject, true);
 
// tell the srho that it is not a keyword query any more
FieldInfo isKeywordQueryField = searchResultsHiddenObjecType.GetField("m_bIsKeywordQuery", BindingFlags.NonPublic | BindingFlags.Instance);
isKeywordQueryField.SetValue(searchResultsHiddenObject, false);

The code for this is really pretty simple (aside from the reflection). Had the SearchResultsHiddenObject been marked public, we could have had this functionality over a year ago, but oh well.

Installation

Installation is relatively simple and instructions are included in a readme file in the document. A solution package has been provided for ease of installation. Once the package has been installed activate the Wildcard Search Web Part feature on your site collection. I went with a site collection feature because the search center site does not have a web part gallery in it. Now that the feature is activated, go to your results page in your Search Center, edit the page, and add the Wildcard Search Core Results Web Part to the Bottom Zone. You can then remove the old CoreResultsWebPart. Also note that this web part requires .NET Framework 3.5 because I used LINQ to XML to parse through the SelectColumns property.

Usage

Once you have the web part installed, you can perform a wildcard search by just adding an asterisk to whatever you type in the search box. For example app* would return mataches on app, apple, and application. You can also set the Always Use Wildcard property in the Miscellaneous property settings to always perform a wildcard search.

One thing to note. Wildcard searches reek havoc on your search relevance. Where you might be used to having nice clean looking results with your keyword searches, your wildcard searches will look different. It might not always be obvious why a particular item was returned in the search results. The best thing to do is try and see if it works for your particular situation.

This type of web part probably could have been sold, but I thought it was more important to give it to the community. This feature gets asked for by MOSS customers all the time. Finally there is an easy solution to implementing it. Since this web part is new, I am sure there are going to be issues with it. Please, log any issues you run into in installation or in us on the issue tracker of the CodePlex site. Currently, it only supports simple keyword queries. I still need to implement support for passing scopes and managed properties, so look for that in an update soon.

You can find the release files at CodePlex.

Corey Roth is a MOSS consultant for Stonebridge.

How to: Check for nulls when using LINQ to XML

CoreyRoth — Wed, 06 Feb 2008 22:54:00 GMT

I continue to work with LINQ to XML, and I thought this might be worth mentioning (although it is somewhat common sense). An issue often when working with XML attribute (or elements) is that they might not always exists (i.e.: they are null). Therefore, you need to check for this. Specifically, this is an issue when you are assigning attributes into a new anonymous type (although it could occur using a regular type as well). Consider the following example. What if MyColumn is not present in some of the Item elements in the XML document? The code would end up throwing an exception when you tried to enumerate items.

var items = from item in assetTypes.Elements("Item") select new

{

Name = item.Attribute("Name").Value,

MyColumn = item.Attribute("MyColumn").Value

};

How do you fix it? First you use the Any() method of the attribute to see if any of that attribute exist. Then it is just a matter of using shorthand if/then syntax. Just replace MyColumn with the code below.

MyColumn = item.Attributes("MyColumn").Any() ? item.Attribute("MyColumn") : null

As you can see it is relatively simple, once you know to use Any() to look for the existance of an attribute. On a related note you can apply the same techique to see if an element exists.

How I used LINQ to XML to Create Document Library Folders

C-Dog's .NET Tip of the Day — Thu, 17 Jan 2008 23:29:24 GMT

I have been doing a lot of document library work lately and in my work I had a need to create a series of subfolders in the document library using a particular custom content type. This meant I was going to need to write a little code. I decided to keep...(read more)