Disposing of Objects Correctly in MOSS or WSS 3.0

One of the big "gotchas" in coding against the SharePoint Object Model is not disposing of resources properly.  In relatively little time, you can find that your server is cycling itself to free up resources, with no apparent reason.  The first thing you should check is your own code.

Roger Lamb has written an excellent, in-depth article called SharePoint 2007 and WSS 3.0 Dispose Patterns by Example about how to fix these issues.  When my client had memory leak issues, they first wanted to blame the third party Web Parts that they had installed and they uninstalled them.  No joy.  After much back and forth with Microsoft (I was out of the loop on much of this), they were pointed to Roger’s post.  Making all of the changes that Roger recommended solved the problems.

These weren’t "big deal" Web Parts, either, but they were called frequently.  Every time that they were called, they held onto a little bit of memory until everything was brought to its knees.  No matter that they were running big iron for their farm; memory is finite, and eventually you will use it all up.

Another excellent resource is an article that Roger references in his post from Stefan Goßner entitled Dealing with Memory Pressure problems in MOSS/WSS.

While computing has changed drastically since my early days of writing assembly and FORTRAN, smart use of memory never goes out of style!

“The form cannot be displayed because session state is not available.” Error in SharePoint UI-Based Workflow Configuration

My client was seeing an odd error in one of their environments, bot not any of the others.  When you would go to configure an out-of-the-box workflow on a site, you’d see the "The form cannot be displayed because session state is not available." error after clicking Next on the first configuration screen (/_layouts/AddWrkfl.aspx).

Some research pointed to several different potential causes, each of which lay in the Shared Service Provider (SSP) settings.

The first one told us to check the Form Session State in the SSP configuration below (/_admin/ipfsConfig.aspx).  Clearly a good idea, but no joy.  (I didn’t find this one, so I don’t have the source.)


The second idea was the winner.  Thanks to Ishai Sagi in Canberra, Australia for this one:

Open the web.config file for the site, search for the word "SessionStateModule" and uncomment that line.

<!– <add name="Session" type="System.Web.SessionState.SessionStateModule"/> –>
should be:
<add name="Session" type="System.Web.SessionState.SessionStateModule"/>>

It’s not clear to me how this line would have been commented out in the first place (I have no access to the servers or to Central Administration), but this was the fix that worked.

Displaying the Document Type Icon in a DVWP in SharePoint

Oftentimes you’d like to mimic the out of the box display capabilities of SharePoint when you create a view using a DVWP (Data View Web Part or Data Form Web Part).  One of the things you might like to do is to show the document type icon for the documents in your view.  These are the little icons that you see in views where you display the Type column for a Document Library, but you might want to show these icons in other cases as well.

By default, these icons are stored in _layouts/images.  This maps to the C:/Program Files/Common Files/Microsoft Shared/web server extensions/12/TEMPLATE/IMAGES folder in the SharePoint hive.  If you look in that folder, you will see thousands of images, but most of the document type icons take the form IC[Document Type].GIF.  So the Microsoft Word icon is ICDOC.GIF.

The information about which icon is displayed for each document type in stored in the DOCICON.XML file which is stored in the hive at C:/Program Files/Common Files/Microsoft Shared/web server extensions/12/TEMPLATE/XML.

The DOCICON.XML file contains mappings for the document type values (the document extensions):

<Mapping Key="doc" Value="icdoc.gif" EditText="Microsoft Office Word" OpenControl="SharePoint.OpenDocuments" />

as well as for the program IDs:

<Mapping Key="Word.Document" Value="ichtmdoc.gif" EditText="Microsoft Office Word" OpenControl="SharePoint.OpenDocuments" />

Finally, the DOCICON.XML file contains a default icon to use in case there isn’t anything specific about the document type or program ID for the specific file.  By default, this is the icgen.gif icon — the generic icon.

This is all well and good, but how do you take advantage of this well thought out scheme?  Well, the trusty yet surprisingly undocumented ddwrt: namespace comes to the rescue once again.  (Thank goodness for this article from Serge van den Oever or all of this would be an unknown mystery.)

There are two ddwrt functions that you can take advantage of here: GetFileExtension and MapToIcon.  So, all of this complexity can come down to one simple line to display the document type icon:

<img alt="Type" src="/_layouts/images/{ddwrt:MapToIcon('', ddwrt:GetFileExtension(string(@FileLeafRef)))}"/>

In this example, I want to display the document type icon for a file stored in a Document Library, so I am using the @FileLeafRef column (friendly name: Name).  First I call GetFileExtension to pull out the file extension (e.g., doc).  Note the type conversion to string.  As I have mentioned in previous posts, many of the ddwrt: functions require this explicit conversion.  Next, I pass that file extension to the MapToIcon function.  The MapToIcon function takes two arguments: Program ID and File Extension.  Since I don’t know or care about the Program ID in this case, I leave it blank and just pass in the File Extension.  All set: the compound function passes me back the document type icon, easy as pie.

“Cannot get the list schema column property from the SharePoint list” Error with Excel 2003

This seems to be a fairly widespread issue with no clear solution.  It occurs when the user chooses the ‘Export to Spreadsheet’ Action and the SharePoint list view has a Date/Time column displayed.  With Excel 2007, the data is exported to Excel just fine, but with Excel 2003, the above error is shown in a popup.

I’ve seen several suggested workarounds:

  • Change the Date/Time column to a ‘Single line of text’ column, download, and then switch it back. (This may destroy the Time value.)
  • Remove the Date/Time column from the view.
  • etc.

None of these workarounds are perfect, but at least they can get the data downloaded for you.  The ideal solution seems to be to upgrade to Excel 2007, which is much more SharePoint (and especially MOSS) aware.

Encoding Query String Values Between .ASPX Pages

I ran into an instance today where a column’s data contained the ampersand (&) character when I hadn’t expected it to.  Since the ampersand is used to separate Query String name/value pairs in the URL, that ampersand was causing me problems.

In general, you should always encode Query String values just in case they might contain a reserved character.  Here’s the code snippet from my page (In another section of my XSL, I pass the selected value on the Query String.):

            <xsl:if test=”@Business_x0020_Group = $Group”>
                <xsl:attribute name=”selected”>true</xsl:attribute>
            <xsl:attribute name=”value”>
                <xsl:value-of select=”ddwrt:UrlEncode(string(@Business_x0020_Group))” />
            <xsl:value-of select=”@Business_x0020_Group” />

As you can see in the bolded line, the ddwrt:UrlEncode function takes care of things for me.  Note that you must do the explicit type conversion to string or you will get an error.  (This is the case with most of the ddwrt namespace functions.)  In the case where I had a Business Group with the string ‘[RR&C]’ in it, the ddwrt:UrlEncode function returned ‘%5bRR%26C%5d’, which can be passed as a Query String value with no issues.