Configuration Information for Workflows

In the workflow I’m working on, some xPaths. I don’t want to hard code them, as this is the sort of crap that always changes. However, I’m not sure where a good place to store such properties would be. I’d figured the workflow.xml file, or even features.xml, but I didn’t find information about doing this. All it’d need is a series of properties and values, but neither seems to do that.

I guess I could write an association form – but given that this workflow will only be used on one list, and that the settings shouldn’t change very often, this would be like using an anti-aircraft gun to kill a mosquito.

It is really frustrating to have simple tasks, no documentation, and no answers. I mean, come on guys, all I want to know is the right way to install a config data, and access it.

Configuration Information for Workflows

More on Updating SharePoint Workflow Tasks

So, I’ve continued investigating my problems updating a SharePoint Workflow Task. I decided to learn about event receivers, as this is what the message was about.

Event receivers, well, receive events that happen on an item, and process them. I listed the ones on my workflow task list with the following code:

for (int j = 0; j < myList.EventReceivers.Count; j++)
{
SPEventReceiverDefinition d = myList.EventReceivers[j];
Log (d.Assembly + " - " + d.Class + " - " + d.Data + " - " + d.Filter + " - " + d.Name + " - " + d.Type.ToString());
}

This gave the the results:

31/08/2006 11:13:57 – Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c – Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver – – – – ItemAdding

31/08/2006 11:13:57 – Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c – Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver – – – – ItemUpdating

31/08/2006 11:13:57 – Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c – Microsoft.SharePoint.Workflow.WorkflowTaskUpdateEventReceiver – – – – ItemDeleting

31/08/2006 11:13:57 – – – – – – 32767

It turns out that there is an easier way of list the event receivers, but dumping to a log file works. Interestingly, he also had the same 32767 result, which is weird. It’s (2^15)-1, so presumably the highest value that can be represented by a 16bit signed integer – but what is it doing in my log?

Anyway, I reckon that the ItemUpdating event receiver is killing my update – but don’t effing know why.

Incidentally, this is a good article demonstrating event receivers. Shame about the bugs they’re finding, though.

More on Updating SharePoint Workflow Tasks

Updating SharePoint 'Workflow Tasks'

Problems doing the simplest things. I want to update a task created by the CreateTask activity, when the activity is changed. I have the following function, which is run when the Task list item is edited…

private void onTaskChanged1_Invoked(object sender, ExternalDataEventArgs e)
{
SPWeb mySite = new SPSite(workflowProperties.SiteId).OpenWeb(workflowProperties.WebId);
SPList myList = mySite.Lists[workflowProperties.TaskListId];
SPListItem myTask = myList.GetItemById(TaskBeforeProperties.TaskItemId);
SPUser myUser = mySite.AllUsers[e.Identity];
myTask["Assigned To"] = myUser;
myTask.Update();
}

Everything seems okay, but when I call myTask.Update(), I get the exception “An event receiver has cancelled the request.” And I’m damned if I know why.

Updating SharePoint 'Workflow Tasks'

Error in SharePoint Logs – Load Workflow Assembly: System.IO.FileNotFoundException

This one puzzled – the file name in the Workflow.xml ‘CodeBesideAssembly’ was correct, and I thought the PublicKeyToken was okay too. Turned out that the ‘version’ was wrong – it seems to start at 3.0.0.0, but my assembly was only 1.0.0.0. Dunno why that was.

Error in SharePoint Logs – Load Workflow Assembly: System.IO.FileNotFoundException

Why Geeks shouldn't write Documentation…

Just came across this paragraphy in some of the documentation for Windows Workflow Foundation. The first sentence is okay, but it goes downhill from there…

Workflow Task Content Types

By default, all SharePoint task types are assigned content types. If you do not specifically assign a content type to a task type, the task type uses the Task base content type. All task-type content types must be based on the Task base content type.

WTF?

Why Geeks shouldn't write Documentation…