Issues in debugging custom workflow assemblies

Three months ago, I wrote a post about profiling workflows with custom activity step -> Debugging custom workflow assemblies

There were couple of comments in the post, about it not working as expected due to

Different version of CRM and/or
Different version of Plugin Registration tool

I will now give you the steps to get this working.

Install LINQPad -> https://www.linqpad.net
Install CRM Driver for LINQPad -> https://crmlinqpad.codeplex.com/

After creating a connection to your CRM instance, run this LINQ query

XNamespace mxswa = "{clr-namespace:Microsoft.Xrm.Sdk.Workflow.Activities;assembly=Microsoft.Xrm.Sdk.Workflow, Version=8.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35}";
var query = from w in WorkflowSet.AsEnumerable()
where
w.Name == "[YOUR WORKFLOW NAME WITH CUSTOM STEP]" &&
w.FormattedValues["type"] == "Definition"
&& w.IsCrmUIWorkflow.GetValueOrDefault()
orderby w.ModifiedOn descending
select new {
w.Id,
w.Name,
WorkflowVersion = XElement.Parse(w.Xaml).Attributes().FirstOrDefault(a => a.Name.LocalName == "mxswa").Value.Split(';')[1],
CustomSteps = from a in XElement.Parse(w.Xaml).Descendants($"{mxswa}ActivityReference")
			   where !a.Attribute("AssemblyQualifiedName").Value.Contains("Microsoft.Crm")
			  select new {
			  CustomStepName = a.Attribute("DisplayName").Value,
			  AssemblyName = a.Attribute("AssemblyQualifiedName").Value,
			  HasArguments = a.Descendants($"{mxswa}ActivityReference.Arguments").Any()}
};
query.Where(c=>c.CustomSteps.Any()).Dump();

You’ll get something like this. Note that the workflow in my case is “Blank Workflow with Custom Step”. Change this to the one you are trying to profile.

Issue 1: Cannot see the workflow step.

If you cannot see the workflow step, that means that there is a mismatch between the Microsoft.Xrm.Sdk.Workflow.dll version and/or your custom workflow step version. Go the folder with the Plugin Registration tool and check the version of the Microsoft.Xrm.Sdk.Workflow.dll version. The important thing is if the major version or minor version of the Microsoft.Xrm.Sdk.Workflow.dll assembly in Plugin Registration tool folder, is different from the one in the Workflow XAML, you will not see the step displayed.

CRM 2016 Plugin Reg Tool — CRM 2016 Plugin Registration Tool

CRM 2016 Update 1 Plugin Reg Tool.png — CRM 2016 Update 1 Plugin Registration Tool

Compare this with the results of the LINQ query and confirm that the major version and minor version match. Do this same for your custom workflow assembly as well.

Issue 2: NullReferenceException

There is a bug in the Plugin Registration Tool, that doesn’t allow you to profile workflow steps, that doesn’t have any argument. If you try to do this, you will get this exception.

Null Reference.png

The workaround for this is to add a dummy argument, to keep the plugin profiler happy.

Workflow

Hope this helps with your debugging efforts.

13 comments

Debugging custom workflow assemblies | Dreaming in CRM says:

Jul 1, 2016 at 3:02 pm

[…] (01/07/2016): Please refer Issues in debugging custom workflow assemblies where I address the issues in the […]

Reply
- shahzaman sadiq says:
  
  Aug 30, 2018 at 9:33 pm
  
  i am facing same issue .it is giving object not set to an instance error.i have tried
  [Input(“Dummy Argument for Profiler”)]
  [Default(“Dummy Argument for Profiler”)]
  public InOutArgument DummyArgument { get; set; }
  But issue is same .
  i am using Microsoft dynamic 2016 crm plugin registration tool.
  can you please help me out.
  
  Reply
{Custom activity workflow Debug error} Syntax error in cast operator; two arguments separated by comma are required. – AK' MSCRM BLOG says:

Dec 1, 2016 at 4:17 am

[…] refer below links https://dreamingincrm.com/2016/02/26/debugging-custom-workflow-assemblies/ https://dreamingincrm.com/2016/07/01/issues-in-debugging-custom-workflow-assemblies/ Hope it’ll help […]

Reply
Jannes says:

Feb 14, 2017 at 7:29 pm

hi i have a problem, where my profiled workflow is running into an infinite wait status when triggered.
Unprofiled workflow is running fine and i can’t find any error messages. Did you come across this one yet ?

Reply
jamazz says:

Feb 14, 2017 at 7:31 pm

I have a problem where my profiled workflow is running into infinite wait after triggering.
Unprofiled one is running fine and i cant find any error messages. Did you come across this one yet ?

Reply
- Natraj Yegnaraman says:
  
  Feb 15, 2017 at 9:16 am
  
  You profile the workflow step and run the workflow with suffix profiled. This workflow doesn’t complete and waits indefinitely. Is this the situation? Can you please post it in the forums so that you can share some screenshots?
  
  Reply
a says:

Feb 16, 2017 at 1:32 pm

1 day of struggle and this page sorted it out !!!! Legend !!!!

Reply
- Natraj Yegnaraman says:
  
  Feb 16, 2017 at 1:37 pm
  
  I had the exact same experience. It was only after many hours of trial and error and decompiling, I figured it out. Glad you found it useful 😊
  
  Reply
  - a says:
    
    Feb 16, 2017 at 3:49 pm
    
    Thanks mate,
    I am currently stuck on this
    The following errors were encountered while processing the workflow tree:
    ‘DynamicActivity’: The private implementation of activity ‘1: DynamicActivity’ has the following validation error: Compiler error(s) encountered processing expression “DirectCast(CustomActivityStep1: another dummy text_1_converted, System.String)”.
    Syntax error in cast operator; two arguments separated by comma are required.
    
    I have checked the link above you have suggested, but that didn’t helped.
    Do you see anything obviously wrong in this code ?
    I am struggling for a while….
    
    public class WorkflowClassTest : CodeActivity
    {
    [Input(“Dummy Argument”), RequiredArgument]
    [Default(“Guid”)]
    
    public InArgument DummyArgument { get; set; }
    
    [Input(“Dummy Argument 2”), RequiredArgument]
    [Default(“EntityLogicalName”)]
    
    public InArgument DummyArgument2 { get; set; }
    
    [Output(“Fetch Output”), RequiredArgument]
    
    public OutArgument FetchOutput { get; set; }
    
    protected override void Execute(CodeActivityContext executionContext)
    {
    ITracingService tracer = executionContext.GetExtension();
    IWorkflowContext context = executionContext.GetExtension();
    IOrganizationServiceFactory serviceFactory = executionContext.GetExtension();
    IOrganizationService service = serviceFactory.CreateOrganizationService(context.UserId);
    
    try
    {
    //DummyArgument = “abc”;
    
    }
    catch (Exception e)
    {
    throw new InvalidPluginExecutionException(e.Message);
    }
    }
    }
a says:

Feb 16, 2017 at 5:07 pm

ok found the solution, whatever input variable you have in the profiled wf, add any dummy value to it save and rerun.. adding default value was not working for me.
Cheers
Bharat

Reply
Sushmitha Ganesh says:

Oct 22, 2017 at 8:24 pm

Also one of the reasons which may go unnnoticed is , sometimes a single system workflow has the same custom workflow step twice. Even if these 2 steps have different input arguements, the profiler won’t work for system workflows with multiple steps referring to same workflow. to debug such workflows, only have a single step for each custom workflow .

Reply
Jeetendra Das says:

Dec 27, 2017 at 6:25 pm

i followed the steps to add dummy argument but not resolved

Reply
- Natraj Yegnaraman says:
  
  Jan 9, 2018 at 7:14 am
  
  Did you restart the async service (if it is OnPrem) after the workflow change? Try recycling the apppool if you can as well and confirm that the new argument has indeed come through.
  
  Reply