Hello,
I am getting the following error when trying to load a workflow dynamically:
System.IO.FileLoadException was unhandled
Message="The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)"
The code that errors is as follows:
using System.Reflection; ... Assembly assembly = Assembly.Load(@"C:\Path\SequentialWorkflowLibrary.dll"); ... |
SequentialWorkflowLibrary is a sequential workflow library that works without problems inside of its own project. I get this error when trying to execute the workflow from a separate console host.
I made the following change when troubleshooting:
... Assembly assembly = Assembly.LoadFile(@"C:\Path\SequentialWorkflowLibrary.dll"); ... |
The change seemed to take care of the FileLoadException, unfortunately a new error presented itself a couple of lines down when trying to start this workflow:
... Type type = assembly.GetType("SequentialWorkflowLibrary.Workflow1"); ... workflowRuntime.StartWorkflow(type, System.Guid.NewGuid()); ... |
I get the following error when calling StartWorkflow:
System.IO.FileNotFoundException was unhandled
Message="Could not load file or assembly 'SequentialWorkflowLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified."
Any comments to help me get past this issue would be greatly appreciated!
Regards,
JM
Loading Workflows from assemblies: FileLoadException
AutomationTool_Brad
This is not a flaw with accessing Workflow Libraries. Serialization and Deserialization also occurs at other stages during workflow execution e.g. when a persistance point is hit. Also your workflow can have dependencies/references/custom types that will have to be resolved and again, you will either have to copy them over or resolve them dynamically. This type resolution is done by .NET and it requires that the assembly be either present locally, or in the GAC or a path be provided to it. So in your case where you want to load and run workflows dynamically the best option does seem to populate your own lookup to handle the type resolutions. We do a similar thing with our test infrastructure as well.
Thanks,
Vihang
niupigege
Regards,
JM
DLivingston766
StartWorkflow clones the workflow tree during which it does serialization and deserialization and looks for the assembly. Since the assembly is not in GAC or in the local path, it fails. So you have couple of options.
1) Copy over the assembly locally and load it from there
2) Subscribe to AssemblyResolve and have the handler return the assembly from remote location.
AppDomain.CurrentDomain.AssemblyResolve += new ResolveEventHandler(CurrentDomain_AssemblyResolve);
static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
return Assembly.LoadFile(@"C:\remotepath\WorkflowLibrary2.dll");
}
Hope this helps,
Vihang
sriramnaga
Michael Hogue
To help with further my understanding:
1) Are there any fundamental logic flaws with trying to access Workflow Libraries from directories other than the local path
2) Assuming the above is not the case, if I were to implement a host that dynamically receives the path of a workflow assembly from another source (ie user input) and then executes a specified workflow within that assembly, it seems that handling remote paths would be in my best interest. That being the case, I would have to write the AssemblyResolve handler to know which assembly was being loaded and return the path as needed. Off the top of my head it seems like I would have to populate a lookup so that the AssemblyResolve handler could lookup the remote path based on the assembly being loaded. Does this seem accurate
Forgive me if I am wildly off-base here.
Thank you again for your clarifications!
Regards,
JM