This is what this post is about: how to get that folder (by name) in C# in a performant matter.

Let’s get down to business: what I would like to do is write a function that takes in a folder name and it returns me the SPFolder object (in the first level, not recursively), for this I have several options:

• You can try SPList.Folders and loop over that
• You can do SPList.RootFolder.SubFolders

The first issue you might encounter with SPList.Folders is that it actually queries the whole list, meaning each and every item in that list recursively.

The code behind the Folders property is here:

public SPListItemCollection Folders
    {
      get
      {
        SPListItemCollection listItemCollection = (SPListItemCollection) null;
        if (!this.HasExternalDataSource)
          listItemCollection = this.GetItems(new SPQuery()
          {
            ViewAttributes = "Scope=\"<strong>RecursiveAll</strong>\"",
            Query = "<Where><Eq><FieldRef Name=\"FSObjType\" /><Value Type=\"Integer\">1</Value></Eq></Where>"
          });
        return listItemCollection;
      }
    }

This means that if you have – by default – more than 5000 items you will have an SPQueryThrottledException which is something we like to avoid.

SPList.RootFolder.SubFolders obviously does not have this limitation, unless you have more than 5000 folders under your rootfolder.

The other implication of this recurveness is that querying SPList.Folders is considerably slower than going through SPList.RootFolder.SubFolders.

Here are some figures (I show the code at the end of this post):

As you can see, going through RootFolder.SubFolders is way faster. On a sidenote: use Cast() instead of OfType() to be able to query it through Linq to Objects as it is one hell of a lot faster.

The code of the test:

public static SPListItem GetFolder1(SPList list, string folderName)
        {
            var results = from f in list.Folders.OfType<SPListItem>() where f.Title.Equals(folderName, StringComparison.InvariantCultureIgnoreCase) select f;
            if (results.Count() == 1)
                return results.ToList<SPListItem>()[0];

            return null;
        }

        public static SPListItem GetFolder2(SPList list, string folderName)
        {
            var results = from f in list.Folders.Cast<SPListItem>() where f.Title.Equals(folderName, StringComparison.InvariantCultureIgnoreCase) select f;
            if (results.Count() == 1)
                return results.ToList<SPListItem>()[0];

            return null;
        }

        public static SPListItem GetFolder3(SPList list, string folderName)
        {
            var results = from f in list.RootFolder.SubFolders.OfType<SPFolder>() where f.Name.Equals(folderName, StringComparison.InvariantCultureIgnoreCase) select f;
            if (results.Count() == 1)
                return results.ToList<SPFolder>()[0].Item;

            return null;
        }

        public static SPListItem GetFolder4(SPList list, string folderName)
        {
            var results = from f in list.RootFolder.SubFolders.Cast<SPFolder>() where f.Name.Equals(folderName, StringComparison.InvariantCultureIgnoreCase) select f;
            if (results.Count() == 1)
                return results.ToList<SPFolder>()[0].Item;

            return null;
        }

• ListDeleting
• ListDeleted

These don’t get hit when the parent site gets deleted, meaning you have to be very careful with it. If you really want to execute the logic that is contained within those events, you need to do it in the WebDeleted / WebDeleting events aswell.

Our initial investigation showed us that there is not that many information to be found on this subject so we decided it was time to share some information on the subject.

There are a few ways of implementing this, but each one of them has its advantages and drawbacks.

You can for example – in the case of custom webparts – implement custom logic to forcefully prevent the use of webparts in certain sites. This big disadvantages here are that you have to implement this additional logic to your webparts and this is obviously an overhead we can miss. You can not use this method for OOTB webparts either.

Another way would be to put item level security on the webpart files and just let trained users have access to it. This has obviously drawbacks that those privileges users can still add those webparts

We chose for a more modular approach by using CSS in combination with a delegate control. The advantage here is that it’s modular, but it can be overridden by a savvy power user.

In the sample below I will create a feature that will remove the “Content Rollup” category from the insert webpart ribbon:

To do this I created a new user control with the following CSS inside:

div.ms-wpadder-categories > div[title="Content Rollup"] {
        display: none;
}

Afterwards you need to create a new empty module and add the following to the elements.xml file:

<Control Id=”AdditionalPageHead” Sequence=”50” ControlSrc=”~\_controltemplates\Your_project\Your_usercontrol.ascx” />

After this you add a new feature (web scoped) to the solution and add the newly created module to this feature.

When you deploy your solution and activate your feature the web parts with category “Content Rollup” will be hidden.

As you can see in the screenshot below, the “Content Rollup” category is hidden for end users.

If you need to just hide specific webparts you can also use the following CSS:

div.ms-wpadder-items > div[title*="Your_contains_statement"] {
           display: none;
}

My ideal solution would be something that is scalable and takes into account the security of the User Profile Application.

The solutions that I found all shared the same approach:

• Open the User Profile Application Service
• Get the count of user profiles
• Get X numbers between 0 and the number of user profiles
• Get those user profiles

I do have some issues with this which I would like to point out:

The count of the number of user profiles requires you to use an administrative account, which often works in a development environment (single machine, one account to rule them all kind of gig).. but when you deploy to a real live SharePoint farm you might encounter problems such as:

• The account used with the SPSecurity.RunWithElevatedPrivileges might not be administrator of the User Profile Application, thus giving you an access denied. This means going through even more unconfortable steps to get this working.
• If you try to iterate over your User Profiles it goes quite slow (do not try to iterate over 10000+ userprofiles, you’ll be stuck for minutes)

What my suggestion would be is to make use of the SharePoint search API and look for your user profiles there, the SharePoint search is very scalable and gets your results much faster than then the regular user profile API.

using (SPMonitoredScope scope = new SPMonitoredScope("Get random profiles"))
{
StringBuilder Output = new StringBuilder();

FullTextSqlQuery q = new FullTextSqlQuery(SPContext.Current.Site);
q.QueryText = "SELECT AccountName,FirstName,LastName,PictureURL,Path FROM Scope() WHERE \"Scope\"='People' AND Contains(PictureURL, 'http')";
q.ResultTypes = ResultType.RelevantResults;
q.RowLimit = 10000;
ResultTableCollection results = q.Execute();
ResultTable queryResultsTable = results[ResultType.RelevantResults];

DataTable queryDataTable = new DataTable();
queryDataTable.Load(queryResultsTable, LoadOption.OverwriteChanges);

Random random = new Random();
int randomId = random.Next(queryDataTable.DefaultView.Count - 5);

DataTable dataTableToBind = new DataTable();
List<string> columns = new List<string>() { "AccountName", "FirstName", "LastName", "PictureURL", "Path" };
foreach (string column in columns)
dataTableToBind.Columns.Add(column);
for (int id = randomId; id < randomId + 4; id++)
dataTableToBind.ImportRow(queryDataTable.Rows[id]);

rptUserProfiles.DataSource = dataTableToBind.DefaultView;
rptUserProfiles.DataBind();
}

The result can be as follows:

Note:

• In the above example one random ID is chosen and then it takes the next X random profiles to show, you can also take just X random profiles but then you would need to add some extra logic to it to avoid duplicates.
• It is also recommended to cache the results you get back for performance reasons.
• The above code is not production proof, it is a simple POC

Just a closing note: if you try to iterate the user profiles through the user profile API you will quickly be stuck for seconds or even minutes, so it is highly recommended not to try this approach.

The method of using the search API is highly underused in my opinion and should be used as much as possible for the iteration over items that are spread across the farm, including – but not limited to – the search of user profiles.

Special thanks to Stéphane Eyskens (http://www.silver-it.com/)!

Sourcecode: http://www.skavi.be/wp-content/uploads/2011/09/Skavi.UserProfiles.zip

My specialities in the field of SharePoint are:

• Coaching
• Consulting
• Development
• Analysis
• Training

Have a nice day!