Our application generates workflows programmatically. Since the number of workflows (DLLs) can be quite large we would like to store the DLLs in a special folder so that they are not mingled with the application files. The problem is that when the application tries to execute a workflow, the runtime cannot find it. I have seen similar questions and the recommendations were to put the workflows in GAC or program folder. If we were to put them in GAC, it means we need to sign them, register, unregister, etc., which will degrade performance (and we do not want to fill GAC either). Another suggestion was to include the private path in the .config file, but if I understand it correctly the path must include the file name, but since we generate the files on the fly we cannot do it either. Is there a simple solution to address this problem, like adding a folder to the PATH environment variable in Win32
P.S. I posted this question at the beta newsgroup but did not get a response, so I thought I would try it here since this forum has been pretty helpful in the past.

How to load workflow assembly from a specific directory?
Mhd. akram
Lagear
There most certainly is a way to do this. You need to add dynamic type/assembly resolution in order to achieve this.
AppDomain
.CurrentDomain.TypeResolve += typeHandler;AppDomain.CurrentDomain.AssemblyResolve += asmHandler
You can store your dynamically generated workflow assemblies in a collection and when the .NET runtime attempts to search for them and fails to find them, it will call your handlers to provide the required assembly/type. See http://msdn.microsoft.com for examples and details on these .NET APIs.
Thanks!
Angel
BobK_MN
< xml version="1.0" encoding="utf-8" >
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="MyWorkflows"/>
</assemblyBinding>
</runtime>
</configuration>
The only issue I see (in this scenario) is that if I have two hosting apps, they would not be able to share the same workflows if they (hosting apps) are deployed to different folders. I do not anticipate this to happen, so it should be OK. It would be nice to be able to easily load a workflow from a directory that does not belong to the application folder, though.
Todd West
MizzouTiger
This is fine...the above solution will still work given the information you have available (the path to the assemblies). In your assembly resolve handler, you can search the required assembly in the specified folder by name (which is provided in the event args of the handler) on a per need basis (every time your handler is called), load that assembly, and return it.
Of course, you could avoid all of this if the target folder is a child folder of the application directory and specify the "probe private" config entry.
Thanks,
Angel