Greg Manrodt's Blog

Unexpected Error

gmanrodt — Thu, 13 Mar 2008 18:56:00 GMT

Perhaps this was obvious to all but me, but I thought I would post it anyway.

I am sure all SharePointers out there have seen, and perhaps been plagued by the above error. Well, there is now hope.

Go to the web.config file for your particular SharePoint Web Application, and open it in your favorite editor. At the top, set (forgive the XPath) '/configuration/SharePoint/SafeMode/@CallStack' to "true". Then set '/configuration/system.web/customErrors/@mode' to "Off". Finally, set '/configuration/system.web/compilation/@debug' to "true". Suddenly, your "Unexpected Error" becomes a "traditional" ASP.NET error that you can actually debug. Now why did I think of this before??

Big kudos to Jimmie Thompson from Microsoft Consulting Services for pointing this out.

Uncustomized vs. Customized (Ghosted vs. Unghosted)

gmanrodt — Fri, 31 Aug 2007 19:26:00 GMT

In SharePoint Portal Server 2003 (and WSS 2.0) it was a simple task to discover the ghosted status of pages in your SharePoint environment. Simply run "select * from docs where content is not null and leafname like '*.aspx' and listid is null". And to reghost them, all you have to do is set the content to null again.

In Microsoft Office SharePoint Server 2007 (and WSS 3.0), things have become substantially more complicated. In order to alleviate the performance impact of customizing (unghosting) pages, and to alleviate the design burden of modifying SharePoint's look and feel, Microsoft uses Master Pages and Page Layouts to handle the design of a single page in SharePoint. Unfortunately, this means that the content field is almost never null for a page in the database. So how do you figure out if a page is customized?

There are three ways, I will start with the worst way, and work my way up:

1. The SPFile object has a property called CustomizedPageStatus, which maps to an enumeration. The values of the enumeration are Customized, Uncustomized and None. (I really wonder what "None" means in this context. It seems to me customized and uncustomized are mutually exclusive, as well as comprehensive.) In the case of a Publishing Page object, i.e. an ASPX page in a "Pages" library with the publishing feature activated, this enumeration always == Customized. I check it like this:

foreach (SPListItem item in List.Items)

{

if (PublishingPage.IsPublishingPage(item))

{

NumberOfPages++;

PublishingPage pPage = PublishingPage.GetPublishingPage(item);

if (pPage.ListItem.File.CustomizedPageStatus == SPCustomizedPageStatus.Customized)

{

Console.WriteLine(pPage.Url + " is customized.");

}

2. The second way is to use PublishingPage.IsDisconnected. This method works much better than the first I mentioned, except in one (admittedly extreme) circumstance. This circumstance is when you have a publishing page object which does not have any assigned page layout. (Even customized (unghosted) pages have a page layout to fall back on.) The only time I have seen this circumstance is when migrating a SharePoint Portal Server 2003 portal, with a custom site definition for areas, and having a "Page Template Upgrade Definition" file fail. The upgrade will still work (no errors, no warnings), but the pages created have no page layout and are "broken".

3. The last method, by far the most reliable it to use SharePoint designer. SharePoint Designer seems to infallibly detect the customization status for any page. The trouble here of course, is that SharePoint Designer can not be put into a script like the first two methods, there fore limiting optimization.

Reasons to Migrate

gmanrodt — Thu, 28 Jun 2007 18:36:00 GMT

Many organizations have some kind of SharePoint deployment, whether it is a full intranet using SharePoint Portal Server 2003 or a collection of disconnected Windows SharePoint Services sites to manage department or project documentation. The idea of upgrading these sites to the newest version of SharePoint can seem a daunting task, especially if you remember/experienced a similar migration path from SharePoint 2001 to your current implementation. Though the effort is not trivial, it is well worth it, for the features and improvements in the new version.

Here are some of the key benefits gained from the previous version, broken down by SharePoint version.

SharePoint Portal Server to Microsoft Office SharePoint Server

Web Content Management - SharePoint now offers WCM capabilities, like browser-based page editing, reusable content, site collection image libraries and content scheduling. SharePoint also has cross-server deployment capabilities, to ensure that deployments are scheduled and controlled.

Business Data Catalog - The Business Data Catalog provides the SharePoint instance to use line of business data (from SQL, Oracle, SAP, Siebel, et cetera) in lists, web parts, and search.

Excel Services - Excel Services allows viewing Excel Spreadsheets on the web (no Excel need be installed on the client). Excel services will also perform scheduled recalculations of the spreadsheet. The web parts available to view the Excel sheet are also very powerful (no more Office Web Components!! Woohoo!), giving organization the ability to quickly create dashboards of their critical business data.

Forms Server - Forms Server allows for the storing, managing and viewing of InfoPath forms via the SharePoint server. InfoPath forms can now be published as web forms, by passing the need for the InfoPath client to be installed.

Search - The search in SharePoint hass been completely redone. The search that comes with MOSS is a fully-capable, customizable enterprise search. For search alone, I believe many organization would consider the upgrade.

Windows SharePoint Services v2 to v3

Workflow - Workflow in SharePoint fully leverages the .NET Framework 3.0. However, there are still two options here. Workflows in SharePoint can be designed in Visual Studio 2005 and deployed as a feature (assembly), but they can also be designed by business (non-technical) users in SharePoint Designer. The SharePoint Designer interface is wizard driven, intuitive and surprisingly powerful.

Event Handlers - Synchronous and Asynchronous Event Handlers (for all list types, not just libraries). See here.

Content Types and Site Columns - Content types and site columns allow companies to define metadata at a higher level than the list or document library. This means that you could define a content type called "project plan" and another called "design specification." Both columns could reuse existing site columns, such as "project type" and "business line" but could also define their own fields, specific to those content types. Then SharePoint sites across the organization could leverage that content type on multiple libraries. Content types also define the document template to be used for that content type, minimizing the deployment of new document templates.

Search - Even the search in WSS has improved. WSS is no longer leveraging SQL Server Full Text search, and instead is using a newly developed indexing engine, which is much more robust.

Solutions and Features - Solutions and features make up a new deployment model for enabling new capabiliteis in SharePoint. Not only does the provide a more succinct mechanism for deploying capabilities, but audit of thos capabililties as well.

SharePoint Event Handlers, Part 2

gmanrodt — Wed, 27 Jun 2007 18:45:00 GMT

In my previous post, I described the current state of event handlers in MOSS and WSS v3. Also, I listed the available event that can be handled by developers' custom code. In this post, I would like to vent, just a bit, on some of the challenges that I have faced implementing event handlers on a custom list.

My first challenge is concerning deployment. This is rather easily solved, by implementing a free tool to manage the connection between your event handler assembly and event(s) which it will handle. Deploying this bugger is a bit tedious, but at least it is well documented. For more, check Brian Wilson's posts. He does a good job of explaining how to write your first event handler.

Now, on to the meat of this post: my second challenge. (Let me apologize now if this is esoteric. I can't help myself.) I would like to talk about the SPItemEventDataCollection object.

In my particular case, I am using a synchronous event handler, so that I can abort the updates to the list item if they do not meet the business rules. I want to check each field in the list, determine which fields have values that have changed, compare them against the business rules and take some action.

When you override one of the event handling methods in the SPItemEventReceiver class, you are passed an SPItemEventProperties object. This object contains tons of useful information, such as the list item which fired the event (which in turn can get you to the list, the web or the site collection objects.) This object also has two very interesting members, AfterProperties and BeforeProperties, which are of the type SPItemEventDataCollection.

Your immediate inclination at this point might be to loop through the BeforeProperties collection and compare its values to the corersponding values in the AfterProperties collection, but you would be misguided. The BeforeProperties.count == SPListItem.Fields.Count, however the values for every field in BeforeProperties == null. I also tried the AfterProperties.ChangedProperties collection with similar results. Everything is null. After some research, I discovered that this class is only used in event tied to document libraries. Bummer.

All is not lost, however, since you can access the SPListItem object trough the SPItemEventProperties object. Now, I can just compare them, right? Almost. The values stored in the AfterPropereties collection are all stored as strings, compared to the SPListItem, which stores some its fields as SPField objects. Comparing their values is far from straightforward. I'll give you a couple of examples.

Single-valued Person lookup fields are stored as just their ID, where ID is a string representation of their integer User ID (ID field in the userinfo and userdata tables). Multi-valued Person lookup fields store the user information as ID;#domain\username;#ID;#domaing\username... (One other thing to note here: If you enter the user's email addres into a Person lookup field, the corresponding AfterProperties value will be null. Entering their name or user id works fine.)

DateTime fields are stored as GMT in AfterProperties, but as local time in SPListItem, so don't try to just DateTime.Parse((string)properties.AfterProperties["MyDateField"]), unless of course you live in Greenwich, England. Otherwise your values will be off (in my case they were off by 7 hours, since I am CST and have Daylight Savings).

All this being said, I am sure that it added less than 10% more code to my 600 line event handler. But they are things to watch out for, especially if you expecting the AfterProperties to store your list item changes as their respective SharePoint types (SPFieldDateTime, SPFieldUrl, et cetera).

SharePoint Event Handlers, Part 1

gmanrodt — Wed, 27 Jun 2007 18:21:00 GMT

Let me begin by saying some nice things about SharePoint event handlers. <Aside>I am talking here of course about MOSS and WSS v3</Aside> Microsoft has really opened the doors on SharePoint, allowing developers unprecedented granularity in handling SharePoint events.

Event handlers in SharePoint come in two flavors: synchronous and asynchronous. The synchronous events occur during processing of the event, allowing the developer to cancel the event if necessary. Asynchronous event handlers are like the ones from SPS 2003 and WSS v2. The handlers will be called some time after the event has fired, but may or may not occur before the event completes its processing. For example, the ItemUpdated event on list items may finish updating the item in question before the event handler attached to it fires.

This approach gives developers a lot of flexibility for how they want to implement their event handlers. In WSS v3, you can now bind events to lists, sites or content types. Here are the events (note that synchronous events end with -ing, asynchronous with -ed):

Lists

FieldAdded
FieldAdding
FieldDeleted
FieldDeleting
FieldUpdated
FieldUpdating
EmailReceived
ItemAdded
ItemAdding
ItemAttachmentAdded
ItemAttachmentAdding
ItemAttachmentDeleted
ItemAttachmentDeleting
ItemCheckedIn
ItemCheckedOut
ItemCheckingIn
ItemCheckingOut
ItemDeleted
ItemDeleting
ItemFileMoved
ItemFileMoving
ItemFileConverted
ItemUncheckedOut
ItemUncheckingOut
ItemUpdated
ItemUpdating

Sites

SiteDeleted
SiteDeleting
WebDeleted
WebDeleting
WebMoved
WebMoving

Content Types

In my next post, I will go into some nitty gritty details on my experience dealing with these event handlers. It has not all been pretty. Stay tuned.

SharePoint 2007 and Office 2000/XP/2003

gmanrodt — Fri, 18 May 2007 20:13:00 GMT

Are you running an older version of Office and wondering how your organization will fare with Windows SharePoint Services v3 or Microsoft Office SharePoint Server 2007? There are a lot of features that come with Microsoft Office 2007, but what is "business critical" vs. "nice to have" when it comes to the "ribbon" or the SharePoint metadata bar at the top of your Word 2007 documents?

And what about basic functionality, like open document from a document library, saving them back to SharePoint and check-in/check-out?

Thankfully, Microsoft has written a whitepaper which describes the features and functionality in each Office platform to help set your expectations (or more importantly, your management's expectations).

Extending STSADM

gmanrodt — Fri, 18 May 2007 13:31:00 GMT

In MOSS and WSS v3, it is now possible to extend the functionality of stsadm (pronounced s-t-s-admin). For those who may not know, stsadm.exe is located (in a typical installation) at c:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin. Stsadm is the primary tool for administrative access to your SharePoint instance, and can be used for scripting mass updates as well. They are many things that can be done from stsadm that cannot be done from anywhere else.

There are of course many benefits to extending stsadm, as its OOB functionality is not exhaustive. One major advantage of extending stsadm is that security privileges are not an issue. Since you have to have administrative privileges to run stsadm in the first place, the whole object model is available to you when writing your own custom operations. This means that you could write operations to gather reporting data against your installation (number of sites, users docs, list items, et cetera) to swapping out versions of a Web Part across an entire installation.

The steps for extending stsadm, run as follows:

Create a Class Library project in Visual Studio 2005.
Have your class inherit from ISPStsadmCommand, which is found in the Microsoft.SharePoint.Publishing namespace.
Implement the two methods from this interface, which are GetHelpMessage and Run.
Write your custom logic in the run method.
Sign your assembly, so that it is strongly named.
Deploy your assembly to the GAC on your SharePoint server(s).
Create an XML file called stsadmcommands.custom.xml, or something similar. The important thing is that the name you give it is not already taken by another file in the CONFIG folder of your SharePoint server. The name stsadmcommands.custom.xml works well. Also, it is not necessary to have a new stsadmcommands.*.xml file for each assembly that you create; a single file can reference all of your custom operations across multiple assemblies.
The content of the XML file should look something like this:

<?xml version="1.0" encoding="utf-8" ?>
<commands>
<command name="operation1" class="namespace.class1,assemblyname,Version=1.0.0.0,Culture=Neutral,PublicKeyToken=fe06441db3bdd371"/>
<command name="operation2" class="namespace.class2,assemblyname,Version=1.0.0.0,Culture=Neutral,PublicKeyToken=fe06441db3bdd371"/>
<command name="operation3"class="namespace.class3,assemblyname,Version=1.0.0.0,Culture=Neutral,PublicKeyToken=fe06441db3bdd371"/>
</commands>

Now, deploy this XML file to (again, in a typical installation) c:\Program Files\Common Files\Microsoft Shared\web server extensions\12\config. When you run stsadm.exe (no parameters) it lists all of the available operations. Your new operations (in this case operation1, operation2, and operation3) should appear in the list. Running "stsadm -help operation1" will call the GetHelpMessage method in the namespace.class1 class.