running the workflow designer multiple times.
I'va build an application that is based on the workflow designer lab.
in the original sample, and so is in my code, once the user has clicked the run button (which executes the workflow) the button goes disabled.
I've been trying to go pass this constraint, but it seems to be a difficult task because once you have run the workflow instance, the dll is held up in the current process and executing the compile() method again, results with the exeption that the customworkflow.dll is is use and can not be written to.
I think this feature is a must in the designer user interface, but i cant get it to work.
i've tried to seperate the execution into two threads but the dll was still on the air.
did somebody encouter this issue?
can somebody think of a resolution?
thanks in advance
[905 byte] By [
urir] at [2007-12-21]
Urir, there are a few options here:
1) Compile your workflows into uniquely named assemblies. If you do this then you will not have the .NET loading conflict which you are hitting.
2) Execute your workflows in a separate AppDomain. What is happening is that you are loading the workflow type into your current AppDomain. This causes .NET to load the assembly into that AppDomain and, therefore, lock it on disk. The only way to unload an assembly is unload the containing AppDomain. So, if you create a new AppDomain you can write remoting code to control a workflow runtime which will run the workflow. When you want to recompile then you would just unload the AppDomain, recompile, and create a new AppDomain to run your new workflow type.
Note that this is not an issue with WF or the designer experience. Rather this is just a side effect of how .NET handles assemblies.