I was recently tasked with creating a quick Sharepoint web part that would require the ability to enter a user and store that user in a list. The overall control was a registration control for various workshops.

The list included a people field so whatever I programmed from the front end would have to supply a valid user. Also in the list were fields for Email and Display Name. All of these of course can be found in the SPUser object. So the control I created would have to convert whatever the input was into a SPUser object.

Above is the simple control I came up with. As this was just meant to be a quick control I decided to use a SmartPart control which is basically just an ASCX user control.

In order to do the above, the best way would be to be include SharePoint’s built in People Picker control. Now here is where things got a little confusing. There is indeed a people picker control however this is not what you are actually looking for. What you really want to use is the People  Editor control.

To use this in your user control you first need to give your control a reference to Microsoft.Sharepoint.WebControls :-

<%@ Register Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"

    Namespace="Microsoft.SharePoint.WebControls" TagPrefix="cc1" %>

Once you have added that reference you are free to use any of the built in SharePoint controls. The one we’re specifically wanting is the People Editor control :-

    <cc1:PeopleEditor ID="BlazerID" runat="server" MaximumEntities="1" 

    MultiSelect="false" AllowEmpty="false" 

    ErrorMessage="Please Enter a User" ValidatorEnabled="true"  />

The people editor control has various properties that you can set. Here I have told it that I only want a single entry (only one person) and that this is a required field.

Now that you have you’re people picker control added to your form, how do you get the value in your code behind and convert it to a SPUser object?

First off I defined an empty SPUser object that will eventually hold the result :-

SPUser user;

The people editor control doesn’t actually return an array of SPUser objects as I would have expected, instead it returns an array of PickerEntities. So first thing you want to do is get the appropriate entry. Since I specified only a single entry I can immediately reference the index of the entry I want :-

PickerEntity ent = (PickerEntity)BlazerID.ResolvedEntities[0];

Next I want to convert this into a SPUser object. There are various ways of doing this but the quickest is to first get the UserID of the username entered :-

int userID = Int32.Parse(ent.EntityData["SPUserID"].ToString());

Once you have that then you can simply get the SPUser object from the sites authorized users collection :-

user = SPContext.Current.Site.RootWeb.SiteUsers.GetByID(userID);

Now that you have a SPUser object you can use all the normal properties associated with a user object (Email, Name etc.).  Here is the code in full I used :-

SPSite site = SPContext.Current.Site;

SPWeb web = site.OpenWeb();

SPUser user;

try

{

    PickerEntity ent = (PickerEntity)BlazerID.ResolvedEntities[0];

    int userID = Int32.Parse(ent.EntityData["SPUserID"].ToString());

    user = SPContext.Current.Site.RootWeb.SiteUsers.GetByID(userID);

}

catch

{

    lblError.Text = "Please enter a valid user";

    return;

}

…….

item[item.Fields["FullName"].InternalName] = user.Name;

item[item.Fields["Email"].InternalName] = user.Email;
item[item.Fields["BlazerId"].InternalName] = "-1;#" + user.LoginName;

……

The (…….) represents code that isn’t relevant here. The end result is a fully working people picker control on your own custom control :-

I’m currently installing Sharepoint Server 2007 in a small farm environment and have come across a bug that I’d previously run into however forgotten about, and have just spent the last couple of hours tracking down the problem yet again.

Therefore hopefully this small posting will save people some time.

The bug applies if you have a small server farm. We are setting up a development environment that has two front end servers and a separate search and index server.

The two front end servers are load balanced and as such I setup MOSS Central Config web application on both of these servers, however the Search and Index server is purely just that and therefore told the initial install NOT to setup Central Admin on this server.

That all works ok however when you come to upgrade your MOSS farm to SP1, the first thing you have to do is upgrade to WSS SP1. After installing the necessary components on your farm you need to run through the Sharepoint Products and Technologies Configuration Wizard in order for the upgrade to take. When you run the Configuration Wizard on a server that does not have central admin installed on it then you will run into a problem. This can be attributed to either the initial MOSS installation not placing a file in the appropriate directory or the WSS SP1 upgrade having a bug in which it insists on that particular file being present when it’s not.

The file in question is web.config which lives in the 12 hive under Template\Layouts folder. If you install Central Admin on your server then the web.config file will be present in this directory however if you do not install Central Admin on your server (as in the case of our Search and Index server) then the initial MOSS install will not place this file in the Template\Layouts folder.

This causes WSS 3.0 SP1 upgrade to fail as it specifically looks for this file.

There is an easy fix to this problem however, simply copy the web.config file over from one of your front end servers, re-run the Configuration Wizard and everything will work fine.