Issue in setting up Visual Workflow Tracking

Question

I used the WorkflowSimulator example from SDK to setup visual workflow tracking on my re-hosted solution but I ran into following problems:

1. Rather than directly loading Workflow from WorkflowDesigner.Load method that takes file path, I used the overload which takes AcitivityBuilder. As a result the LoadFile property in the code below was null. Even after hard coding the physical file path of XAML file the sourceLocationMapping collection did not return any item. The only way it worked was by loading the Workflow using file path overload on Load method of WorkflowDesigner. Is this the desired behavior? How can I run Visual Workflow Tracking on workflows loaded through ActivityBuilder? And how about cases where I persist XAML in database and do not want to use file system at all. How do I perform debugging in that scenario?

Activity documentRootElement = GetRootActivity(rootInstance);
                SourceLocationProvider.CollectMapping(GetRootRuntimeWorkflowElement(), documentRootElement, sourceLocationMapping,
                    workflowDesigner.Context.Items.GetValue<WorkflowFileItem>().LoadedFile);
                SourceLocationProvider.CollectMapping(documentRootElement, documentRootElement, designerSourceLocationMapping,
                   workflowDesigner.Context.Items.GetValue<WorkflowFileItem>().LoadedFile);
            }

2. The code in GetRootRuntimeWorkflowElement method works with the provided sample workflow  but for workflows created in re-hosted environment I had to tweak the code to skip literals (if there were any workflow level arguments) to return the root activity.

 while (enumerator1.MoveNext())
            {
              
                if (enumerator1.Current.Id.Equals("1.1"))
                {
                    root = enumerator1.Current;
                    break;
                }
            }
            return root;

The problem comes only for workflows created in re-hosted environment. Workflows created in Visual Studio does show correct root activity irrespective of arguments at workflow level.

I am not sure where the problem is? I can clearly see differences in XAML for the same workflow from Visual Studio and re-hosted environment. How do I build XAML similar to the one from Visual Studio?

Answer 1

Regarding 1,

This is probably the expected behavior of these APIs.

No concept of File exists if you didn't tell the rehosted app any info about the file. I believe you can call ContextItem.Items.SetValue<WorkflowFileItem>() though. Or in your code above why not pass the file name to CollectMapping directly?

Answer 2

So even if I set WorkflowFileItem on Items as you said above I cannot get list of source locations. It seems SourceLocationProvider.CollectMapping is doing more that I am unaware of. Only if the activity is loaded using WorkflowDesigner.Load overload that takes file path does the SourceLocationProvider.CollectMapping return correct source location mapping. If I build activity object using Activity Builder then it always returns 0 items in the collection.

Even passing the file name to CollectionMapping did not work.

Need your help!

Answer 3

OK, just going to toss out a few more ideas

-Does calling { Load(builder); Flush(); Load(); } instead of just Load(builder) have any effect? (Got a theory that this will create an intermediate text representation to get line number mapping from.)
-How are you loading the activity builder from XAML? (Which API)?
-Does that XAML have the workflow debugger file name attribute in it? Does it make a difference if it does?

If nothing else works, might be worth trying serializing your object out to a temporary file.

Tim

Answer 4

Ok, so more than one Load operation on the same designer instance is not supported through I get inconsistent error in doing so.  Calling Load overload with ActivityBuilder twice throws runtime exception while calling multiple Load with any other combination renders same exception on the designer.

Either ways,  SourceLocationProvider.CollectMapping does not return any sourceLocationMapping. The only way this method works is by loading WorkflowDesigner using filename overload which seems strange.

I tried with XAML file with and without correct XamlDebuggerXmlReader attribute.

This is how I am creating ActivityBuilder:

XamlServices.Load(ActivityXamlServices.CreateBuilderReader(
                new XamlXmlReader(new StringReader(File.ReadAllText(m_FilePath))))) as ActivityBuilder;               
                

Serializing object to a temporary file is going to work but to me it is more like a workaround. In my opinion, given the API is still in beta it is better to deal with such discrepancies within the framework itself unless there is a reason behind it.