Auto Start + VirtualPathProvider....does it work?

Question

I'm extrememly familiar with the concept and implementation of a virtual path provider since I've used them in other projects (e.g. using master pages / page templates / images / etc that are stored in a database) so I'm good with that half of the equation.

I've been doing research on AppFabric's Auto Start feature and It looks rather straight forward, with a couple of expected "gotchas."

My question, however, is whether or not you can auto start services that are exposed through a virtual path provider.  From my understanding, AppFabric crawls the file system in order to find the services that need to auto start, or you can denote them explicitly in the web.config. 

The conceptual problem I have with this is the fact that if there is a "crawling" process going on, there is nothing in the virtual path provider that supports a "list files" operation and that would preclude a "crawler" from discovering the files that existed.

It appears that in all of the examples that use a virtual path provider, the calling application already has a knowledge of what the service's explicit address is.  Therefore a virtual path provider wouldn't have a problem getting that resource's path and then returning it from a repository. In the case of my client applications that have to call the services, there will be a convention that the client can use to determine the workflow's address, which will be intercepted by the virtual path provider and returned from the repository (or cache). So that pattern works well.  But it does not follow the "crawling" paradigm.

So, how (or can) you Auto-start WF services whose definitions are resolved via a Virtual Path Provider?

 

Side Note:

I'm already thinking that I may have to have a work around.  I'd create a static AppInitialize() method that executes as soon as the AppDomain starts.  I'd then create dummy files on the file system that have the same relative path for all of the workflows that are defined in the database that have persisted workflow instances.  these files would not contain anything.  Then when the "crawler" ran, it would be able to have a physical marker for the auto start process.  When it tried to actually start those workflows, the Virtual Path Provider would intercept the calls and then return the actual workflow definitions from the database.  Any newly created workflow definitions that were created after the AppDomain starts would resolve normally.

I do not want to use this work-around, though.

Answer 1

This link (http://archive.msdn.microsoft.com/WCFAfAutoStart) mentions which class to look at in Reflector to see the functionality behind auto-start. It would give you a better idea whether or not it would work with a virtual path provider.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline

Answer 2

I was able to open it up in Reflector and it looks like it uses well-known ASP.NET subfolders for a virtual directory such as App_Code, etc. I was able to find the assembly in the winsxs folder and then I copied it to my desktop so Reflector could open it. I just searched my c: for Microsoft.ApplicationServer.Hosting

For crawling an application it has:
 
private void QueueUpAllServicesInApplication() {

       this.QueueUpConfigBasedServices();

       this.CrawlDirectoryAndQueueUpServicesSafe(HostingEnvironment.VirtualPathProvider.GetDirectory("~/"));

}

so i think as long as your virtual path provider handles the GetDirectory with the ~, this might work. I admit I am not a virtual path provider expert.

Thanks,

---

If this answers your question, please use the "Answer" button to say so | Ben Cline