Clever Geek Handbook

WorkFlow Designer Support with Class Library

I need to add Workflows to an existing solution that already contains a class library and a website. If I add workflows to the class library where they logically fit, I have no designer support. If I create them in a separate project, I have circular dependencies because my domain objects run workflows, and workflows need my domain objects.

What is the preferred architecture to avoid this problem?

+1


source to share


2 answers


If I understand your problem, it would be solved if you had WF designer support in your class library so you can add workflow definitions there?

To get this, you can edit the corresponding 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 WF support.

But as gbanfill said, you can also organize your builds in different ways.

+2


source


How I solve this problem is to split the domain object into a POCO assembly (called Domain) and an assembly of methods that do things on POCO objects (called operations). This means that all other assemblies can include domain objects and transfer data among themselves. So my solutions look like (any assembly can include as many assemblies as possible)



  • website
  • the working process
  • operations
  • domain
0


source






More articles:


All Articles