I need to add Workflows to an existing solution, which already contains a class library and a web site. If I add the workflows to the class library, where they fit logically, I have no designer support. If I create them in a separate project, I tend to have circular dependencies because my domain objects run the workflows and the workflows need my domain objects.
What is the preferred architecture to avoid this problem?
The way I get round that problem is to split the domain object into a POCO assembly (called Domain) and an assembly of methods that do things on thoes POCO objects (called operations). This means that all otehr assemblies can include the domain objects and pass data between them selves that way. So my solutions look like (any assembly can include as many assemblies lower in the list)
If I understand your problem, it would be solved if you had designer support for WF in your class library so you could add the workflow definitions there?
To get that you can edit the according class library project file (*.csproj for C#) and add the following lines:
In the first PropertyGroup:
<ProjectTypeGuids>{14822709-B5A1-4724-98CA-57A101D1B079};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>
At the bottom of the file:
For VS2008:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.5\Workflow.Targets" />
For VS2005:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\Windows Workflow Foundation\v3.0\Workflow.Targets" />
Once the project is reloaded in the IDE, you should get support for WF.
But as gbanfill mentioned, you could also organize your assemblies differently.