In Visual Studio hat man beim Anlegen eines neuen Projektes die Auswahl zwischen vielen verschiedenen Projekttypen.

Wie vielerorts empfohlen, macht es bei Workflow Projekten meistens auch Sinn, die Runtime und die Workflow Definitionen in verschiedenen Assemblies abzulegen. Wenn man dann in einer Workflow Library eine neue Workflow Definition einfügen will, sind für die Items auch entsprechende Vorlagen verfügbar.

Wenn man aber mit einer normalen Class Library loslegt, und dann später gerne darin noch Workflow Definitionen oder eigene Activity Typen unterbringen möchte, funktioniert das nicht. Es reicht offenbar nicht aus, wenn man die entsprechenden Referenzen auf die WF Assemblies setzt.
Der Workflow Designer wirft einem eine nicht allzu aufschlussreiche Fehlermeldung “The service ‘System.Workflow.ComponentModel.Design.IIdentifierCreationService’ must be installed for this operation to succeed. Ensure that this service is available.” an den Kopf.

Weshalb? Eine Workflow Library ist doch nichts anderes als ein als DLL kompiliertes Assembly.
Man könnte nun ein neues Workflow Library Projekt anlegen, und alle vorhandenen Dateien hinüberziehen. Es gibt aber auch einen anderen Weg.

Beim Vergleich von zwei Projektfiles stellt man folgendes fest: Im ansonsten völlig identischen Projektfile (.csproj)  der Workflow Library findet man die folgenden zusätzlichen Einträge:

In der ersten PropertyGroup:
[Code language="XML"]{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}[/Code]

Zuunterst im Projektfile (Visual Studio 2008):

[Code language="XML"][/Code]

Für Visual Studio 2005 muss dieser Eintrag auf das .NET 3.0 Framework verweisen:

[Code language="XML"][/Code]

Man kann das Projektfile ausserhalb von Visual Studio bearbeiten, die IDE wird das Projekt automatisch aktualisieren. Danach stehen auch die WF Projektitems zur Verfügung.