Leon Zandman’s Blog

Last week I was refactoring some of my SharePoint code. I stumbled on a loop that created a new SPQuery instance for each iteration. The code was something like this:

   1: SPList list = GetCommentsList();

   2: const string VIEWFIELDS = "";

   3:  

   4: foreach (string param in params)

   5: {

   6:     // Create fresh new SPQuery instance...

   7:     SPQuery query = new SPQuery();

   8:     query.ViewFields = VIEWFIELDS;

   9:     query.Query = BuildQuery(param);

  10:  

  11:     // And use it...

  12:     SPListItemCollection items = list.GetItems(query);

  13:     ProcessItems(items);

  14: }

As the value of the ViewFields property remained the same for each iteration I decided to create just one SPQuery instance and reuse it, like this:

   1: SPList list = GetCommentsList();

   2: const string VIEWFIELDS = "";

   3:  

   4: // Create just one SPQuery instance...

   5: SPQuery query = new SPQuery();

   6: query.ViewFields = VIEWFIELDS;

   7:  

   8: foreach (string param in params)

   9: {

  10:     // And reuse it...

  11:     query.Query = BuildQuery(param);

  12:     SPListItemCollection items = list.GetItems(query);

  13:     ProcessItems(items);

  14: }

To my surprise this code didn’t work! The first time the SPQuery instance was used it worked just fine. However, during the next iterations of the foreach loop it didn’t seem to get updated.

So, what have we learned today? Never reuse SPQuery instances!

Well… That’s not entirely true. You can reuse SPQuery instances for a very valid reason. If you use the RowLimit property you can limit the number of items returned in the query, which is useful for paging as seen in this sample code (taken from MSDN):

   1: using (SPWeb oWebsiteRoot = SPContext.Current.Site.RootWeb)

   2: {

   3:     SPList oList = oWebsiteRoot.Lists["Announcements"];

   4:     SPQuery oQuery = new SPQuery();

   5:     oQuery.RowLimit = 10;

   6:     int intIndex = 1;

   7:  

   8:     do

   9:     {

  10:         Console.WriteLine("Page: " + intIndex);

  11:         SPListItemCollection collListItems = oList.GetItems(oQuery);

  12:  

  13:         foreach(SPListItem oListItem in collListItems)

  14:         {

  15:             Console.WriteLine(oListItem["Title"]);

  16:         }

  17:         oQuery.ListItemCollectionPosition = 

  18:           collListItems.ListItemCollectionPosition;

  19:         intIndex++;

  20:     } while(oQuery.ListItemCollectionPosition != null);

  21: }

So, only reuse SPQuery instances if you use paging. If you change the actual CAML query you should create a new SPQuery instance for it.

I might have happened to you too: make some error in a Windows virtual machine and your system will *BEEP* out loud. Not some nice and fancy WAV/MP3 sample, but a raw *BEEP* coming straight from your system’s motherboard. This *BEEP* does not respect your speaker volume and mute settings. And it will probably irritate most people who sit near you.

Fortunately getting the beep to shut up forever is relatively simple. Here’s how to do it:

1. Open a Command Prompt window (in Vista make sure you open it using the “Run as administrator” option).
2. Use the following commands:
• To stop the Windows Beep Service:
  net stop beep
• To make sure it never gets started again:
  sc config beep start= disabled

That should take care of them BEEPs

The Visual Studio & .NET Framework Evangelism team did it again. After their cool .NET 3.5 Training Kit they are now working on the follow up: the .NET 3.5 Enhancements Training Kit. It’s not final yet, but still very interesting!

Currently, the training kit contains six hands-on labs, made up of the following technologies:

1. ADO.NET Data Services
2. ADO.NET Entity Framework
3. ASP.NET AJAX History
4. ASP.NET Dynamic Data
5. ASP.NET MVC
6. ASP.NET Silverlight controls

Read more about it on Jonathan Carter’s blog.

Beware of the SharePoint Memory Leaks!

You might not know it, but when developing for SharePoint (either WSS 3.0 or MOSS 2007) it is very easy to cause memory leaks, which can ultimately thrash your SharePoint server’s performance. The reason for this is that even though your own code might be written using only managed code, the SharePoint API still uses unmanaged code in some places. These unmanaged resources have to be explicitly disposed of, especially considering the fact they are living inside an ASP.Net web application (SharePoint) and potentially can have a long lifetime.

The problem is that the SharePoint API doesn’t always make clear when exactly you have to dispose of objects explicitly. Sometimes it may look like you’re just inspecting a value of a property, while in the background a whole new object is instantiated, which holds valuable unmanaged resources that should be freed by the caller (you!). Other times you might find yourself disposing an object, only to find out you weren’t supposed to…

Way back in June 2006 Microsoft employees Scott Harris and Mike Ammerlaan released their article Best Practices: Using Disposable Windows SharePoint Services Objects on MSDN, which can be regarded as the mother of all articles on this subject. I think this article is often overlooked and should be considered essential reading material for every serious SharePoint developer out there. Also read their more recent article called Best Practices: Common Coding Issues When Using the SharePoint Object Model, which also handles topics like data and object caching and writing scalable code.

Recently two other Microsoft employees also wrote interesting pieces on this subject. Stefan Goßner did a piece called Dealing with Memory Pressure problems in MOSS/WSS, in which he explains what a "Memory Pressure Situation" is and he lists some common causes and solutions for it. The other interesting read came from Roger Lamb. His entry is called SharePoint 2007 and WSS 3.0 Dispose Patterns by Example and in it he shows some very clear code samples and patterns on how to properly handle SharePoint objects.

Very cool material, guys!

Yesterday Jan Tielens released a new version of his famous SmartPart to the community. It is now at version 1.3 and here’s the changelog:

• Added a setup wizard to install the Return of SmartPart.
• Added sample user controls (including connectable user controls and AJAX user controls).
• Added localization support for ASP.NET AJAX user controls.
• Various minor bug fixes.
• Nice 2-minute screencast on how to deploy and test the SmartPart.
• 64 bit version available.

Great work, Jan! I also like the fact you’ve used Lars Fastrup’s SharePoint Solution Installer for deploying SmartPart.