Updating Workflow asembly does not add additional In/Out arguments

[LeszekSzejka]

After registering custom workflow activity with eg. 1 input argument any next assembly update via tool does not ADD new arguments, eg. new input and/or output.

Same operation via SDK version does that.

[shytikov]

Thanks, that's interesting case, actually...

Can you give me version of your CRM organization? Is it Online or OnPrem?

I have seen similar behavior before, though it was more about caching old assemblies by async workers, so it took some addition time to update in CRM...

[rappen]

I have also seen this on occasion, and I think updating build number makes CRM pick upp new arguments.

[LeszekSzejka]

It is 2016 IFD.

On Tue, Nov 22, 2016 at 11:34 AM, Alexey Shytikov [email protected]
wrote:

Thanks, that's interesting case, actually...

Can you give me version of your CRM organization? Is it Online or OnPrem?

I have seen similar behavior before, though it was more about caching old
assemblies by async workers, so it took some addition time to update in
CRM...

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM3EuyM9-ZtmlsOMQInWFPgBdI1d8tySks5rAsUdgaJpZM4K5IGN
.

[LeszekSzejka]

SDK PluginRegistration tool does not require incrementing dll version, even
the build number.
It looks like after initial registering the workflow activity is not being
updated - the summary window after updating assembly is showing only that
assembly has been updated, not the required workflow activity.

On Tue, Nov 22, 2016 at 11:43 AM, Jonas Rapp [email protected]
wrote:

I have also seen this on occasion, and I think updating build number makes
CRM pick upp new arguments.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#16 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AM3EuxgjREFdiRtSb6i5AolLv09x8ixgks5rAsdZgaJpZM4K5IGN
.

[yagasoft]

This issue has been described in detail in a Microsoft article. I summarised it in my blog post below and added an automation feature for it in my Visual Studio extension as well.
https://blog.yagasoft.com/2021/12/missing-custom-step-parameters-oracle-series

I would like to add the following to this plugin (already implemented in the extension above), would that be of interest?

• Select a Plugin Assembly (or Type_s_) as the source and another assembly/type as the target
  • All Plugin Steps will be migrated to their respective type if found
  • All WFs that use a Custom Step in the target assembly will be upgraded to use the new assembly
• Source: Plugin Steps (across different assemblies/types as well), Target: Plugin Type
  • Move steps to the target type
• Source: Plugin Steps (across different assemblies/types as well), Target: Plugin Assembly
  • Move steps to their respective type in the target

Please let me know if you would like to add/improve/replace any of those features.

[imranakram]

Thanks, we have a plugin available for similar functionality called StepManipulationTool https://www.xrmtoolbox.com/plugins/Innofactor.XTB.StepManipulationTool/

[yagasoft]

That's interesting indeed. I checked it out and it does fit some of the requirements.

I have a couple of questions, please:

1. Does it handle WF Custom Steps?
2. Can it automatically match the source Plugin Type, or does the user have to migrate each type individually?

For a plugin assembly upgrade, I feel that the Plugin Registration's UI is a bit more user friendly for such an operation. What do you think?