deploy_plugins / deploy_workflows using a single Library

[khendricks89]

We are using deploy_plugins and deploy_workflows for a while now and recently updated the versions, of which some projects to Beta 382 for MFA.

Recently we can't deploy our Libraries anymore as we mix Plugins and Workflows within a single Project using namespacing instead of splitting these up into seperate libraries.

It however tries to unregister the Workflows during Plugin deployment and vice versa. Do you have a way to deploy both at the same time (like a setting)?

[TclasenITVT]

Could you provide a minimal Repro?

[khendricks89]

@TclasenITVT @scottdurow I can do one even better. Please find below the repro steps and attached the temporary SPKL solution we made to mitigate the issue. The only open point is that it currently tries to register steps for Workflow Activities as well.

Repro steps

1. Create a new Visual Studio C# .NET Library Project (single project / dll)
2. Create a new Plugin within the project
3. Create a new Custom Workflow Activity
4. Deploy the Plugin using the XRMToolbox's Plugin Registration
5. Create a Workflow in Dynamics 365 using the created Custom Workflow Activity
6. Go back to your Visual Studio project and use "deploy-plugins.bat" to deploy the plugin

As a result, the "deploy-plugins.bat" will try to delete the Workflow Activity as it is not a plugin type. However, the Workflow is in the same DLL and should not be deleted. The deployment for us then fails because the Workflow Activity is in use and therefore has a dependency. Please see below for the message.

The attahced zip contains an extensions a colleague of mine made to resolve this issue. The new function is called "deploy_pluginandworklows".

SPKL pluginandworkflows.zip

Please let me know if you have any questions. I am also available for a Teams meeting.

[teppolainio]

I wandered here to leave an issue for this exactly same case (i.e. to be able to write plugins and workflow activities into same assembly).

I took code provided by @khendricks89 and did initial merge to my own fork. I will PR during next week. I still look a bit into writing command help and checking that attributes given to codeactivity are correctly put into CDS.

[teppolainio]

On PR #302 new command line argument /e was added. This command line argument was added by @ryanmichaeljames to excludes plugin steps from the plugin deployment in order to speed up deployments when only assembly was updated and no steps were updated.

As an outcome of this current issue there will be new task pluginandworkflows which will update both plugin steps and custom workflow activities from single solution. Yesterday my initial though about command line argument /e in conjunction of task pluginandworkflows was to exclude both plugin steps and custom workflow activities from update. On the other hand command line help of the /e says "Exclude plugin steps when deploying plugins". Now I'm wondering about the actual intent of /e. Should it exclude also custom workflow activities when deploying those and plugins in a same operation? Any thoughts about this @scottdurow and @ryanmichaeljames.

[teppolainio]

There is now PR #372 for this feature. Could we get this released into next spkl version in near future so we wouldn't have to use any custom version of it @scottdurow?

This should be non-breaking change as there are only new functionality and one new parameter to old command which defaults to old behaviour. As there weren't any responses to my question above I decided to little adjust behaviour of /e to exclude both plugin steps and custom workflow activity registrarions from update when /e is given from command line.