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.

Now, why have I picked up SharePoint in the first place? Well, sometimes you don’t get to play by your own rules and a client requests that a specific tool be used in the development of his solution and, since the customer is (almost) always right I set up in my trek amidst the tangled jungle of what is possibly the best and worst thing to happen to ASP.NET-based solutions lately. I’ve only worked with the thing for 3 weeks now, so I’m still learning the ropes so I’ll beg your pardon if I speak out of my league. On the surface, SharePoint looks like a real time and money saver, since it offers a lot of functionality straight out-of-the-box. It handles your security, it handles all those nasty things like organizing your users, permissions, groups, websites, content so you don’t have to. Basically you could build a simple Team Site for your small business right from the start, without the hassle of writing code, worrying about exceptions, databases, connections, classes and other outerworldly stuff like that.

What could be wrong with such a real life-saver you ask? Well, the first and most outright flaw is that in protecting your average Joe who just got a job as a website admin at your small business, it also cleverly and sneakily hides errors and exceptions from the naked eye. While I wouldn’t expect such a solution to start spilling it’s guts and present tens of lines of exception traces outright on my screen, I’d still appreciate a bit more than just “An error has occurred!” It would help a lot at least pointing a bit in the right direction rather than fully protecting the feeble minded trainee in the arts of drag-and-drop website creation. It is indeed true that more detailed explanations can be found in the Windows Application Log, but these are more often than not cryptical and sometimes not even very accurate.

A second thing, if you can get over the crappy error reporting system, is that it is as pretentious as it is practical. Upon installation, you are asked whether you would like a Standard or a Server Farm installation. Should you make the tragic mistake of choosing a “Standard” installation, you’ll find out you’ll get more than you bargained for. It will automatically install Windows Internal Database which is basically a named instance of a crippled SQL Server Express Edition [quite straightforwardly named Embedded Edition] and will use that for storing it’s configuration and website tables and whatnot. I have found that SharePoint can be quite buggy and it at one time simply stopped connecting to this Internal Database [conveniently accessible only through a named pipe]. No reason or explanation provided, the whole thing just refused to stop working. The downside is that since I selected “Standard” on installation, I couldn’t just go back and change to “Server Farm” mode. I had to uninstall the blasted thing, manually remove it’s registry residues and reinstall using the other option.

A third thing would be that it’s quite buggy. As I’ve said above, at one time it simply stopped connecting to it’s damned Internal Database after I have deleted and added a site collection. Also, you sometimes run into an “unknown error” here and there that might stunt your workflow. The backup system is simply appalling. While practical in theory by letting you backup your whole website so that it can be moved to another server you run into the impossibility of actually choosing whichever path you’d like for your backup. You have to provide a UNC path that it has write permissions on. While I could overlook this total lack of common sense of not being able to backup to a local physical path, God help you if your website database is hosted on a remote server, because to backup your database, it’ll run some stored procedures from within it’s own database and you’ll soon find that your UNC path is well… unknown to that remote server where you keep your database. And then you’re stuck in a no-exit situation where you can backup the local portion of your website, but your database is stuck somewhere in limbo since it doesn’t even try to download it somehow, but tries to do everything remotely. Quite a showstopped if you ask me. Thank God that for us geeks there’s always the stsadm command line tool that seems to get the job done faster and better than the graphical interface.

But don’t be discouraged. While I think there are many more problems with WSS than I managed to find in my short 3 week experience using it, there are many upsides too. It takes care of arduous tasks so you don’t have to, while you can concentrate on doing the important stuff. It is quite well integrated with your Windows network and with Microsoft’s solutions such as Office, providing full support for documents. And I must admit it’s quite fun to work with and code for to some extent. Debugging options are ok, you can always attach the Visual Studio debugger to the aspnet process. All these said, I’m sure I’d never use WSS to create any solutions except in the exceptional case when it is expressly requested by the client. I suggest you try it out and give it a  go, maybe it’ll make your life easier and maybe the boys down in Redmond will find the time to make it as developer-friendly as it is user-friendly. It has great potential but at the same times major flaws that stop it from being a full-fledged one-stop solution to all of our business demands.