Blog

In ASP.NET you would think when you use the “.Count” method that it would be able to simply return the total number of elements within a collection. In majority of cases this is right. Well, apart from when you use the “.Count” method against a collection of profiles within SharePoint. For example:

UserProfileManager profileManager = new UserProfileManager(myContext);

//Get total number of profiles
int numberOfProfiles = profileManager.Count;

I found that I came across two issues when using the code above:

1. The incorrect number of profiles was returned.
2. For some reason, when I deployed the code to a live server environment I kept on getting errors from the line where the count was being returned.

From researching this issue on various blog posts and forums, it seems that UserProfileManager.Count does indeed have issues in returning the count correctly. The only way to get around this is to enumerate through the UserProfileManager:

UserProfileManager profileManager = new UserProfileManager(myContext);

int counter = 0;

IEnumerator profileEnumerator = profileManager.GetEnumerator();
while (profileEnumerator.MoveNext())
{
    counter++;
}

//Number of profiles
int totalNumberOfProfiles = counter;

This will give us an accurate number of profiles that are stored within SharePoint and without any silly errors.

I have been building a custom .NET web part page to use in my SharePoint intranet. The .NET page has quite a lot of custom HTML and jQuery design elements, so using CSS and JavaScript files were essential.

As you know, when we want to use elements from our CSS and JavaScript files we normally add the following lines of HTML at the top of our page:

<!-- CSS -->
<link type="text/css" rel="stylesheet" href="site.css" />

<!-- JavaScript -->
<script src="jQuery.js" type="text/javascript" />

If you added those lines of code in a custom SharePoint page, you’ll find that the page will ignore them. Thankfully, SharePoint has given us some controls to add these references.

At this point its worth stating that I stored all my required JavaScript and CSS files within the “Style Library” directory situated in the root of any SharePoint 2010 intranet. In order to get these files I used controls called”CssRegistration” and “ScriptLink”:

<!-- CSS -->
<SharePoint:CssRegistration ID="CssRegistration1" Name="/Style Library/Home/CSS/jcarousel.css" runat="server" After="corev4.css" />

<!-- JavaScript -->
<SharePoint:ScriptLink ID="ScriptLink1" Name="~sitecollection/Style Library/Home/JS/jquery-1.4.4.min.js" runat="server" />

If you have stored your CSS and JavaScript within the physical file directory situated in the 14 hive folder, you will need to modify the above example to the following:

<!-- CSS -->
<SharePoint:CSSRegistration Name="<% $SPUrl:~SiteCollection/Style Library/Core Styles/jcarousel.css%>" runat="server"/>

<!-- JavaScript -->
<SharePoint:ScriptLink ID="ScriptLink1" Name="<% $SPUrl:~SiteCollection/Style Library/Core Styles/jquery.js%>" runat="server" />

The only difference between this example and our earlier example is that when we have just added “SPUrl” to get files relative to the current site collection.

I am writing a custom webpart that will output user profile information from SharePoint 2010. My code requires me to get quite a few fields. Most of these fields are not “intellisensable” and cannot be accessed directly without having to manually enter the field name, as you can see from my code snippet below.

But its really easy to get the user field properties incorrect. A good example, is retrieving the office location. You would think the property name would be called “OfficeLocation” but its actually called “SPS-Location”.

Luckily SharePoint allows us to view and access all the user profile properties we require and even create our own custom fields.

Lets start by opening Central Administration and navigate to Manage Service Applications > User Profile Service Application, which will take you to the following page:

Click on “Manage User Properties” to view a list of all user field properties SharePoint uses. To either rename the display name or view the actual property name, click on a field and press “Edit”.

The “Name” field (as highlighted below) is not editable and for a very good reason too! These are the property ID’s that we will call when wanting to retrieve their value. All default field names are not editable.

As I stated earlier, you can create your own properties and call them whatever you want. But SharePoint already provides us with so many out-of-the-box, you probably won’t need to create anymore anytime soon.