VirtualPathProvider

In .Net 3.5, WF services were introduced making it easier to host workflows as services.  With the send and receive activities, a workflow can be used instead of coding a service by hand.  The common way to expose workflows as services is to place the .svc/.xoml or .xamlx files and supporting libraries in the host path.  This works well if you have the workflow definitions stored in files.  If you would like to store your definition in a database or generate the workflow from code, you have to do some of your own coding to make that happen.  By using a VirtualPathProvider, you can use the existing WF services constructs and reduce the amount of infrastructure code you have to write.

One of the reasons I like the VirtualPathProvider is that it provides me a simple way of testing many concurrent workflow definitions without having to code-generate a bunch of files, transfer them to different machines, etc.  When you're trying to memory test 1,000,000 workflow definitions of "average" size, it's best to avoid having a directory with one xamlx file before definition.  One nice part about a VirtualPathProvider is that it doesn't prevent you from creating and using xamlx files.

For this test code, I will walk through creating a VPP that hosts WF4 services.  The first step is to create a new project with the template "ASP.Net Empty Web Application".  I called mine Wf4VppTest.

Read more: dmetzgar

Posted via email from .NET Info