locked
Can uneeded WF 4.0 debugging output be turned off? Thousands of lines of output appear in seconds... RRS feed

  • Question

  • Is it at all possible to turn off workflow 4.0 debugging output that falls into the VS Output window?  My workflow generates thousands of lines of WF debugging in just seconds... (matter of fact, 20K lines).  The output looks like this:

    WorkflowDebugger: Does not have corresponding Xaml node for: InternalReceiveMessage

    WorkflowDebugger: Does not have corresponding Xaml node for: FromReply

    WorkflowDebugger: Does not have corresponding Xaml node for: ToRequest

    WorkflowDebugger: Does not have corresponding Xaml node for: InternalSendMessage

    Unmatched type: System.Activities.Expressions.LambdaValue`1[[System.Uri, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]] vs System.Activities.Expressions.VariableValue`1[[System.ServiceModel.Channels.Message, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]

    Unmatched type: System.Activities.Expressions.VariableValue`1[[System.ServiceModel.Channels.Message, System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]] vs System.Activities.Expressions.ArgumentValue`1[[System.ServiceModel.Activities.CorrelationHandle, System.ServiceModel.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]

    Unmatched type: System.Activities.Expressions.ArgumentValue`1[[System.ServiceModel.Activities.CorrelationHandle, System.ServiceModel.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]] vs System.ServiceModel.Activities.InternalSendMessage+WaitOnChannelCorrelation

    Unmatched type: System.ServiceModel.Activities.InternalSendMessage+WaitOnChannelCorrelation vs System.ServiceModel.Activities.InternalSendMessage+OpenChannelFactory

    Unmatched type: System.ServiceModel.Activities.InternalSendMessage+OpenChannelFactory vs System.ServiceModel.Activities.InternalSendMessage+OpenChannelAndSendMessage

    Unmatched number of children

    WorkflowDebugger: Does not have corresponding Xaml node for: InternalReceiveMessage

    WorkflowDebugger: Does not have corresponding Xaml node for: FromReply

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentValue<BeginApprovalProcessRequest>

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentValue<CorrelationHandle>

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentValue<CorrelationHandle>

    WorkflowDebugger: Does not have corresponding Xaml node for: WaitOnChannelCorrelation

    Unmatched number of children

    WorkflowDebugger: Does not have corresponding Xaml node for: OpenChannelFactory

    WorkflowDebugger: Does not have corresponding Xaml node for: OpenChannelAndSendMessage

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentValue<CorrelationHandle>

    WorkflowDebugger: Does not have corresponding Xaml node for: WaitForReply

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentReference<BeginApprovalProcessResponse>

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentValue<BeginApprovalProcessRequest>

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentValue<CorrelationHandle>

    WorkflowDebugger: Does not have corresponding Xaml node for: ArgumentValue<CorrelationHandle>

    WorkflowDebugger: Does not have corresponding Xaml node for: WaitOnChannelCorrelation

    Unmatched number of children

     

    This does not occur every time I run the WF... but enough to be tiresome.  The WF is XAMLX-based.  

    Thanks in advance

    Thursday, March 24, 2011 12:13 AM

Answers

  • The best answer I have is sadly no.
    There's no feature to turn it off from the workflow debugger side.
    Cleverness with timing the attach doesn't work either, because it's a feature that the workflow debugger can work even after attach to process.
    Hacky trace listener stuff also doesn't work because it is writing directly to Debugger.Log, not Debug.Trace.
    Tim

    • Proposed as answer by Andrew_Zhu Tuesday, March 29, 2011 1:49 AM
    • Marked as answer by Andrew_Zhu Thursday, March 31, 2011 3:35 AM
    Tuesday, March 29, 2011 12:14 AM