Skip to content

January 17, 2007

Making a Custom Activity Work in Your Project (even if you started with a class library)

Most of the time when I’m developing and I have to learn something new – a new API, a new event model, etc. – or I just need to try something that I don’t know whether it will work or not I create a new project (often with a name that begins with the prefix of TEST).  These projects are where I prove out the technology before integrating it with the core code of the project.  The test project always gets cataloged into a special place in the source control system, and rarely gets directly moved into the main project.

However, every once in a while I guess right and I put together a technology proof (test if you prefer) that works like I want the production to work like.  Today was one of those rare days when I created a new Workflow Activity the way I wanted it.

After I got it checked in I did a bit of source control work to share the test code over to the core project so I could include the files.  (I branched after the share so the files are now on their own unique paths.)  I added the working activity to my core project and… it didn’t work.  I got this really ugly error when I tried to open the design surface for the activity.  It said in part:

The service ‘System.Workflow.ComponentModel.Design.IIdentifierCreationService’ must be installed for this operation to succeed. Ensure that this service is available.

After I stared at the screen wondering how to figure this out, searched for answers (and came up with nothing), I started looking into the project file and found that there are two necessary pieces to make the workflow designer surface to work.  The first entry that’s necessary belongs in the <PropertyGroup> and is:

 <ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>

Basically, it’s saying that it’s a workflow project and it’s a C# project.  If you’re using VB, create a new custom workflow activity then open the project file in notepad and you should see a different ProjectTypeGuids node that you can use.

The second part is an import statement that just goes inside of the root <Project> node.  It is:

<Import Project=”$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.0\Workflow.Targets” />

Adding these two entries to your project file makes the workflow extensions work in Visual Studio and can make your custom activity work – even when you started with a standard class library.

Workflow Custom Activity Events

Nearly every example of how to create a custom workflow activity demonstrates the use of the DependencyProperty.  There’s not much new there.  However, few of the examples will show you how to add events to your custom activities.  It’s not that difficult really, they’re still dependency properties with a bit of a spin.  For instance, if you want to implement a MethodInvoking event you can use the following code:

public static DependencyProperty MethodInvokingEvent =

DependencyProperty.Register(“MethodInvoking”, typeof(EventHandler), typeof(NetSendEmailActivity));

 

public event EventHandler MethodInvoking

{

add { base.AddHandler(MethodInvokingEvent, value); }

remove { base.RemoveHandler(MethodInvokingEvent, value); }

}

This should look really similar to the structure of a regular DependencyProperty – because it is.  Other than the non-static property and the name of the Dependency property, everything is the same.

For a full fledged example you can look at “Send E-mail Activity Sample” in MSDN.  (This isn’t a complete replacement for the SharePoint SendEmailActivity to resolve the issues mentioned in my previous post, but it’s not a bad start.)

Recent Posts

Public Speaking