none
Reuse XAML Declarative Workflow in Workflow Service (xamlx) Results in Server Error of System.ArgumentException: An item with the same key has already been added

    Pregunta

  • We attempted to reuse a XAML (declarative activity workflow) in a few places within the same XAMLX and it doesn't appear to allow this.   On the WCF client side, it reported an obscure error of something to the effect of unknown message received and a communication error stating the service instance couldn't be used at this time and to ensure the call order is correct or order delivery guarantee is enabled.   However, this appears to mask the true issue which is on the server side.   Apparently, when the server side WCF end point is trying to start the workflow instance, it throws this error building a dictionary of workflow children...

    System.ArgumentException: An item with the same key has already been added.
       at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
       at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
       at System.Activities.Debugger.InstrumentationTracker.InitializeUninstrumentedSubRoots()
       at System.Activities.Debugger.DebugManager.EnsureInstrumented(Activity activity)
       at System.Activities.Debugger.DebugManager.OnEnterState(ActivityInstance instance)
       at System.Activities.Debugger.DebugController.ActivityStarted(ActivityInstance activityInstance)
       at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

    This fault propogation gets communicated to the client but without much fidelity it seems.

    When we remove the multiple instances of the XAML in the XAMLX, it works fine.   If we use multiple instances of a coded activity in the place of the XAML it works fine.  

    Is this intentional?  It seems odd that a declarative XAML activity can't be reused (in a Workflow Service XAMLX)?   Please advise.   Thanks.

     

    viernes, 01 de octubre de 2010 19:08

Respuestas

  • Further troubleshooting revealed it only happened during a debug session.  It turns out that the issue was any  sad: XamlDebuggerXmlReader.FileName debug attributes on non-root workflow nodes.   Removing this attribute from the declarative activity (XAML) within the parent XAML (or XAMLX) resolves the issue.   I would consider this a bug in WF 4 but this is a work around.

     

     

    • Marcado como respuesta ki mo viernes, 15 de octubre de 2010 21:13
    viernes, 15 de octubre de 2010 21:13

Todas las respuestas

  • Hi,

    ->"We attempted to reuse a XAML (declarative activity workflow) in a few places within the same XAMLX "
    Could explain more about how do you use XAML workflow in WF service?

    If you compose the XAML workflow in the XAMLX way, for example, no Arguments, have Receive activities, checked the CanCreateInstance checkbox of the first Receive activity. then ,if you rename the sufix "xaml" to "xamlx". this workflow will also work as a Workflow Service.

    Regards
    This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support. My Blog:http://xhinker.com "Microsoft Windows Workflow Foundation 4.0 Cookbook"
    miércoles, 06 de octubre de 2010 8:13
  • -> Could explain more about how do you use XAML workflow in WF service?

    We have a XAMLX that has no arguments and has a correlated ReceiveAndSendReply (cancreateinstance property is true on Receive activity).   In our WorkflowServiceHost we load a WorkflowService (WorkflowService wfService = XamlServices.Load(XamlStream)) and then attach the WorkflowService to the WorkflowServiceHost (wfHost = new WorkflowServiceHost(wfService)) and finally open the host using a .Open() to start listening for messages to start the Xamlx workflow.  Pretty typical.  

    The issue is, the Xamlx after the SendReply activity contains a number of code activities and a number of declarative Xaml activities (Add New Item -> Workflow -> Activity (.xaml extension)).   The declarative Xaml activities contain a number of built in and custom code activity shapes from the toolbox.  If we use the same code activity in the Xamlx workflow, it's not an issue.  However, if we try and use a declarative workflow activity (.xamlx) more than once in the Xamlx, the Xamlx workflow validations seem to fail with the duplicate dictionary key listed above.   

     

    jueves, 07 de octubre de 2010 18:15
  • Hi, Ki mo

    Could you send me[xhinker at gmail.com] a sample project.


    This posting is provided "AS IS" with no warranties, and confers no rights. Microsoft Online Community Support. My Blog:http://xhinker.com "Microsoft Windows Workflow Foundation 4.0 Cookbook"
    viernes, 08 de octubre de 2010 9:16
  • Further troubleshooting revealed it only happened during a debug session.  It turns out that the issue was any  sad: XamlDebuggerXmlReader.FileName debug attributes on non-root workflow nodes.   Removing this attribute from the declarative activity (XAML) within the parent XAML (or XAMLX) resolves the issue.   I would consider this a bug in WF 4 but this is a work around.

     

     

    • Marcado como respuesta ki mo viernes, 15 de octubre de 2010 21:13
    viernes, 15 de octubre de 2010 21:13
  • Hi, we are experiencing a similar problem, with a similar task.  We are trying to load and call XAML files dynamically during a XAMLX service request.  This works in all kinds of test and integration tests, until we attach the debugger.  Removing the debugger attribute from the dynamically loaded activity, however, did not help.

    The errror is somewhat different and concerns a variable (declared as implemenations, just as the Paralell activity launching the DynamicActivity instances):

    System.Activities.InvalidWorkflowException: The following errors were encountered while processing the workflow tree:

    'VariableValue<String>': The referenced Variable object (Name = 'ActionVar') is not visible at this scope. There may be another location reference with the same name that is visible at this scope, but it does not reference the same location.

    at System.Activities.WorkflowInspectionServices.<GetActivities>d__0.MoveNext()

    at System.Activities.Debugger.InstrumentationTracker.InitializeUninstrumentedSubRoots()

    at System.Activities.Debugger.DebugManager.OnEnterState(ActivityInstance instance)

    at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)

    This works perfectly when the debugger is not attached, but causes us headaches.  I would be happy to assist if needed to resolve this, which seems to me as a bug.

    martes, 19 de octubre de 2010 6:54