Missing custom step parameters despite update | Oracle Series
Issue
For as far as I can remember (6+ years), workflows have had an issue with the custom-step assembly update process. I will explain the issue in more detail below.
Let’s assume you registered a WF custom step with a single input parameter, and then you add it to a CRM Action. So far, it’s everyday business. Next, you decided to add a second parameter to the custom step. You go about your assembly update business, only to realise that the second parameter is not showing on the UI in the editor.
Herein lies the issue that has stumbled so many.
Investigation
Randomly trying stuff, 6 years back, I discovered that ‘refreshing’ any info related to the custom step in CRM would reflect the updates.
This solution worked until v9 of CRM. In v9.1.4, it worked again, but you had to update the assembly version every time, or it rejected the whole update.
Currently, this does not work at all.
Such code changes are actually considered a ‘breaking change’. Turned out that the platform’s behaviour towards said changes is intentional on Microsoft’s side all along.
Solution
Everything is described in this article by Microsoft: link.
For your convenience, I will describe it here briefly:
- After an update of the code that is considered a breaking change
- Increment the assembly version
- Build the project
- Register the assembly as a new assembly in the Plugin Registration Tool
- Go to any WF or Action that uses this custom step and upgrade the version in the editor
- Delete the old assembly
As an additional bonus, doing the same steps with plugins resolves the ‘missing type’ error on update. However, you must move the steps themselves to the new assembly version.
Tools
My VS Plugin Registration Extension has been updated to automate this process: link.
