Getting Custom Actions to work in SharePoint Designer

I'm writing custom actions (i.e. Activities) for SharePoint Designer at the moment. It's lovely when it works, and incredibly frustrating when it doesn't. The problem is not so much that it's particularly hard once you've got the basics sorted, it's that it's so poorly documented, and so much of it is literally driving blind.

For instance, I've just spent another typical afternoon's debugging session trying to work out the following error in SPD.

The list of workflow actions on the server references an assembly that does not exist. Some actions will not be available. The assembly strong name is ... Contact your server administrator for more information.”

And I assure you, the assembly *does* exist. This is all made even more frustrating by the fact that I'm working against a development install of SharePoint remotely, and TDD just isn't an option here yet. I mean it's awkward enough for local ASP.NET pages, let alone ones that have to run remotely. Then factor in Windows Workflow, which is a horror to run in nUnit. Well, K. Scott Allen has been trying, but it's far from ideal.

So The last few hours have been characterised by making a small change, deploying and GACing assemblies, possibly, recopying .actions files, iisresetting, restarting SPD, screaming, then doing the same thing again. Over. And over. Again.

Basically I'd added a new Activity to my assembly, but it was an extremely simple one, so I'd had the confidence to write it all out by hand. Then I started getting this error, seemingly out of the blue. I looked over and over the code, compared it with a working Activity (One that was still working on a deployed workflow despite SPD apparently thinking it didn't exist.), compared it with the existing SPD activities via Reflector.. naughty, I know ;oP

I finally came upon this post today from Jason Nadrowski, which gave an insight into the problem. God knows how he found all this out, but I'm ever so glad he did.

http://blogs.informationhub.com/jnadrowski/archive/2007/01/12/8128.aspx

Thank you Jason, I tried to post a comment to your blog to say thanks, but it wouldn't let me. So I'm blogging it instead.

Jason's basically pointed out that When SPD loads your custom actions file, it also asks the server to test your objects. If any fail, SPD reports this error. And the server doesn't log the detail or the truth of the fact anywhere. So I don't know who this error message is aimed at. It's too technical for typical end users, it asks them to ask their administrator for more info, except he won't be able to give it, and it's a blatant lie if targetted at developers.

So anyway, armed with this new knowledge, I dug around. And I found my problem. Purely by speculation too. This may be obvious to the few of you who have been playing with XAML since the first Avalon CTP, if it is indeed a DependencyObject constraint, but it was sure news to me.

DependencyProperties need to be named [public property name]Property or they fail to work in SharePoint. so,


public static DependencyProperty EmailProperty =
  DependencyProperty.Register(
    "Email",
    typeof(string),
    typeof(MyActivity)
  );

public string Email {
  get {
    return base.GetValue(MyActivity.EmailProperty) as string;
  }
  ...
}


will work fine, but, freakishly, and not a little infuriatingly,


public static DependencyProperty _depPropEmail =
  DependencyProperty.Register(
    "Email",
    typeof(string),
    typeof(MyActivity)
  );

public string Email {
  get {
    return base.GetValue(MyActivity._depPropEmail) as string;
  }
...
}

will fail with the "assembly does not exist" error. And this is RTM! I do hope they patch it.