What SharePoint won’t tell you and you have to find out for yourself is that whenever you “Close” a WebPart that contains an error it actually remains on the page, even though it’s hidden. Thus, the page will render fine in the browser and you can be happy to have created an error-free page. But what if you later decide to manually make some changes to the page’s code? You will soon find out that trying to open it in the SharePoint Designer will cause an error to appear, which tells you that the operation has failed and that the page is unsafe. The error  message is something like the following:

soap:ServerServer was unable to process request. —> A Web Part or Web Form Control on this Web Part Page cannot be displayed or imported because it is not registered as safe on this site. You may not be able to open this page in an HTML editor that is compatible with Microsoft Windows SharePoint Services, such as Microsoft Office SharePoint Designer. To fix this page, contact the site administrator to have the Web Part or Web Form Control configured as safe.

I have tried to figure out what is wrong and did some searching around and came to the conclusion above. You should use “Delete” to eliminate faulty, unsafe or not-working web parts. If you have been using the former method and are stuck with a page that is apparently uneditable in SharePoint Deisgner, try accessing your faulty page with a contents=1 variable, for example: http://my-example.com/Default.aspx?contents=1. This will load the page in maintenance mode and you will be able to spot and remove the errors and unsafe controls. Be wary that you might notice a good series of “Error” web parts. Those should be the first ones to go after.

After doing the above, try re-opening the page in SPD. You fill find that now you will be able to successfully edit the source code.

Thus, the following would be an example of redundant code that would provide no actual functionality:

SPList uList = SPContext.Current.Site.RootWeb.Lists["Contact Info"];
string fName = ″John″;
string lName = ″Doe″;
string cPhone = ″555-123456″;

for (int i=0;i<uList.Items.Count;i++)
{
   uList.Items[i]["First Name"] = fName;
   uList.Items[i]["Last Name"] = lName;
   uList.Items[i]["Phone"] = cPhone;
}

The code above doesn’t actually do anything, because even though we assign the values we need to the fields and entries we need we don’t tell SharePoint to also update this into its database. The correct way to do this is to call the Update() method after assigning the values to the fields. But in doing this, we also cannot use the uList.Items[index][fieldName] object, because we cannot use the method with it. Instead, we create a separate SPListItem object and assign the respective entry from the list to that object, like in the example below.

SPList uList = SPContext.Current.Site.RootWeb.Lists["Contact Info"];
string fName = ″John″;
string lName = ″Doe″;
string cPhone = ″555-123456″;

for (int i=0;i<uList.Items.Count;i++)
{
   SPListItem theContact = uList.Items[i];

   theContact["First Name"] = fName;
   theContact["Last Name"] = lName;
   theContact["Phone"] = cPhone;

   theContact.Update();
}

I’ll go over the procedures for both MOSS and WSS for comparison.

Microsoft SharePoint Server 2007

For MOSS, the process is fairly straightforward. The following code listing should get you going.

//These are the libraries you need to reference and include in your WebPart class or your SharePoint page
using Microsoft.Office.Server.UserProfiles;
using Microsoft.SharePoint.Portal.Topology;
using Microsoft.Office.Server;

//This is the actual code for retrieving user info in MOSS, include it where needed
ServerContext context = ServerContext.GetContext(SPContext.Current.Site);
UserProfileManager profileManager = new UserProfileManager(context);
Microsoft.Office.Server.UserProfiles.PropertyCollection props = profileManager.Properties;

foreach (Property prop in props)
{
   Response.Write(prop.Name + “<br/>”);
}

ServerContext context2 = ServerContext.GetContext(SPContext.Current.Site);
UserProfileManager profileManager2 = new UserProfileManager(context2);
foreach (UserProfile profile in profileManager2)
{
   UserProfileValueCollection FirstNameProp = profile["AccountName"];
   Response.Write(FirstNameProp[0].ToString() + “<br/>”);
}

Windows SharePoint Services 3.0

For WSS it becomes a bit more tricky. That is because we lack classes the libraries in the example above. WSS stores only partial user info by default, while additional fields and such must be manually added to the list by the website developer/administrator. Apart from that purely administrational issue, the code is also a tad more difficult to implement. Basically, what we do is get this hidden user list and access it not through specialised classes, but like any other normal list and parse through it’s entries and fields. A code example would be the one below which is used to retrieve the user info for the currently logged user.

//These are the libraries you need to reference and include in your WebPart class
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint;
using Microsoft.SharePoint.Administration;

//This assumes you want the WebPart to display basic info about your currently logged in user
protected override void CreateChildControls()
{
   base.CreateChildControls();

   try
   {
      SPSecurity.RunWithElevatedPrivileges(delegate() {
         SPList uList = SPContext.Current.Site.RootWeb.Lists["User Information List"];
         SPUser pUser = SPContext.Current.Site.RootWeb.CurrentUser;
         int i = FindInList(uList, pUser.ID);

         if (i != -1)
         {
            Controls.Add(new LiteralControl(@”<strong>Name: </strong>” + (string)uList.Items[i]["Name"] + @”<br />”));
            Controls.Add(new LiteralControl(@”<strong>Job Title: </strong>” + (string)uList.Items[i]["Job Title"] + @”<br />”));
            Controls.Add(new LiteralControl(@”<strong>Department: </strong>” + (string)uList.Items[i]["Department"] + @”<br />”));
         }
         else
            Controls.Add(new LiteralControl(@”Could not retrieve user info!”));
      });
   } catch (Exception ex)
   {
      Controls.Add(new LiteralControl(@”<strong>ERROR:</strong><br />” + ex.Message + ” at ” + ex.Source + “<br />Stack Trace:<br />” + ex.StackTrace));
   }
}

protected int FindInList(SPList uList, int userID)
{
   for (int i = 0; i < uList.Items.Count – 1; i++)
      if ((int)uList.Items[i]["ID"] == userID)
         return i;

   return -1;
}

Let’s look a bit at the listing and see what do we actually do. First, we use the SPSecurity class to run the code with elevated privileges because the User Information List list is hidden and is not normally visible to normal user, only to those with Admin privileges. Next we set up the uList and pUser objects, the first of which holds the user info list, while the second is a sPUser object holding the basic data for the currently logged in user. I use the FindInList method to retrieve the id of the currently logged in user within the uList.Items collection. Then we verify whether the user was found in the list. If it is there, we show his name, job title and department, else we show a simple message stating we cannot retrieve user info.

Conclusion

Windows SharePoint Services uses a more rudimentary system for providing access to its user base to the common developer. MOSS on the other hand has specialized classes for this, making it easier to access the data in a timely generic fashion through the use of the Property object. Well, we’ll just conclude that this is just one of the many omissions in WSS compared to MOSS, making you curse your days for choosing the free path instead of paying a premium for the full service. I will return with more basic tutorials covering other aspects of SharePoint Services as I progress in my study and use of this piece of software.