SharePoint Sharpener

As most companies are moving to the 64-bit platform of Windows Server and MOSS, more SharePoint developers are adopting this as their main dev environment.

However, if you plan to develop SharePoint workflows in Visual Studio 2008 on your new 64-bit box, you’re going to be disappointed.

Upon creating a new workflow in VS, an “Object reference not set to an instance of an object”-error pops up:

You can still get to the next step in the process where you have to chose the site which will be used to debug the workflow. Here too, you will be faced with an error:

The solution

Well, there isn’t any. Not right now anyway.

The only thing you can do is to continue developing in your old 32-bit environment and then move your WSP to the 64-bit box for installation.

All this is not a bug per se, rather, it’s down to Microsoft’s lack of resources in their dev team:

 
(source)

Hmm…

Many of you have probably encountered the problem where a workflow triggers itself several times because the code carries out one or more Item.Update() commands. This can be extremely annoying because running extra workflows can be taxing on the server – even if you make sure that the extra workflows don’t make any changes to the element.

Then, you may have discovered Item.SystemUpdate() which in theory should rid the list of the all the extra instances of workflows because it doesn’t trigger an update event and thus flies under the radar of the workflow engine.

This seemed to work just fine for a while. Lately, however, it seems that SystemUpdate() has startet triggering events just like a normal Update().

Post Service Pack 1?

I found that many of my workflows now started behaving differently, i.e. they began triggering multiple instances of workflows.

It took me a while to realise that it probably was a “bug fix” in SharePoint SP1 that was causing the problem.

A glance at the documentation for SystemUpdate() reveals that events are indeed triggered:

There is no mention of SP1 but I assume that this was when the changes were made.

Solution

This is bad news for many developers but obviously a design decision at Microsoft so things probably won’t be changed back to the way they were.

From now on you have to make sure that your workflows only make changes to elements when needed. I.e. you need to only use Update() and SystemUpdate() when they are really needed and thereby minimise the number of redundant workflow cycles.

Alternatively, you could look into programming your own event handlers to obtain more granular control of when events are triggered. I may explore this subject in a future post.