4

I am facing an issue with my custom workflow activity when I try to update it. Once I do a change on the logic the update is done normally, but when I add new input parameters the changes are not reflected.

Changing the assembly version I am no longer able to update the assembly on CRM.

B. Irena
  • 169
  • 7

2 Answers2

4

You are right that you have to change the assembly version to be able to see the new parameters you have added

The assembly with the increased (major/minor) version number should be registered as a new assembly in CRM (instead of as the same one, as it seems you are trying to do).

In the words of Microsoft: Upgrade a custom workflow activity

  1. Make necessary changes in the underlying code of the custom workflow activity.

  2. Change the values for <major_version> and/or <minor_version> in the assembly information of the custom workflow activity, and compile it. For example, change the value of your assembly from “1.0.0.0” to “2.0.0.0”.

  3. Register the upgraded custom workflow activity as a new assembly. Make sure that the new assembly has the same Name, PublicKeyToken, and Culture as the existing assembly to be considered as a different version of the same assembly.

    After you upgrade the custom workflow activity, existing running process instances that are using the custom workflow activity will continue to use the older version of the custom workflow activity assembly. This ensures that your existing running process instances do not break. If you want the process to use the new version of the custom workflow activity, you must modify the process definition to use the new version. Dynamics 365 displays all the <major_version> and <minor_version> combinations for an assembly in a drop-down list for you to select from.

Henrik H
  • 5,747
  • 1
  • 21
  • 33
2

I've run into the same issue. If I don't want multiple assemblies (as @Henrik describes) I follow these steps:

  1. Settings > Customizations > Customize the System
  2. Plugin Assemblies
  3. Select my custom assembly
  4. Select my custom workflow step affected by the upgrade
  5. Show all Dependencies
  6. Deactivate all dependent workflows
  7. Remove the custom workflow step from every dependent workflow (take lots of screenshots)
  8. Use Plugin Registration Tool to unregister the custom workflow step
  9. Use Plugin Registration Tool to update workflow assembly
  10. Update all workflows to use the new custom workflow step, referring to your screenshots! :)
  11. Activate all workflows

This forces all processes (workflows) to use the latest version of the assembly. The same sequence of steps is required if you're removing custom workflow input arguments or adding output arguments

Hopefully you don't have too many affected workflows.

jasonscript
  • 6,039
  • 3
  • 28
  • 43
  • This is exactly what I am doing but the workflow is used many times and this service goes down at least for 1 hour every time I update and I want to avoid this. – B. Irena Jul 30 '18 at 12:14
  • 1
    That's why you have a dev environment. There is no other way of doing this that I'm aware of – jasonscript Jul 31 '18 at 01:42
  • 1
    Henrik's answer is the recommended method by Microsoft at the moment. – Ahmed Elsawalhy Dec 11 '21 at 22:36
  • @AhmedElsawalhy I agree; however Henrik's approach means existing processes will continue to use the old assembly. The steps I've detailed in my answer will result in all processes using the latest assembly. It's more work but it answer's the OP's question directly. Hope this clarifies why I have left this answer in place – jasonscript Dec 14 '21 at 03:39
  • @jasonscript, please read Microsoft's approach carefully: the steps explicitly state that you have to 'move' everything to the new assembly. It's easier when you don't have the luxury of deleting everything and starting again. I used to follow your approach as well for years, but it was hell for us! – Ahmed Elsawalhy Dec 14 '21 at 09:32