How to sync Workflows and Plugins that are in one project (dll)?

[RemyDuijkeren]

I'm using Daxif from C# in my build (NUKE https://nuke.build/) which works well. Now I'm trying to merge my custom Workflows and Plugins projects into one Extensions project (and therefore one dll).

My code executes the following steps, which work if the Workflows and Plugins are in separate dll's.

        DG.Daxif.Workflow.Sync(
            env: SourceEnvironment,
            assemblyPath: SourceDirectory / "Extensions" / "bin" / Configuration / "net462" / $"{SolutionInfo.baseNamespace}.dll",
            solutionName: SolutionInfo.name,
            isolationMode: null,
            logLevel: null
        );

        DG.Daxif.Plugin.Sync(
            env: SourceEnvironment,
            assemblyPath: SourceDirectory / "Extensions" / "bin" / Configuration / "net462" / $"{SolutionInfo.baseNamespace}.dll",
            projectPath: SourceDirectory / "Extensions" / "Extensions.csproj",
            solutionName: SolutionInfo.name,
            dryRun: false,
            isolationMode: null,
            ignoreOutdatedAssembly: null,
            logLevel: null
        );

I expected that the registration would of Workflows and Plugins in one dll would go well.

What happens is that the second step (DG.Daxif.Plugin.Sync) removes the custom workflow activities that are registrated in the step before.

Is there a way the prevent the removing of custom workflow activities when syncing plugins? First syncing the plugins and than the workflows doesn't work.

[magesoe]

We have never tried this. Is there a specific reason why you have code activities and plugins in one project? Just asking out of interest, since I don't know if there are any major reasons why we have 2 different projects, other than they are different things

[RemyDuijkeren]

if there are any major reasons why we have 2 different projects, other than they are different things

I think this kind of became the standard, because people in the past assumed namespace=project and Microsoft also did it this way.

If you look a the deployement life cycle, I don't think they are that different. Usually you deploy both dll's to the same server at the same time. Usually it is workflows and plugins together, that extends Dynamics 365 and makes a solution work. Also If early-bound types are updated, then it is usually safer to deploy both projects even if only one of them changed.

Also for me, at an abstract level, workflows and plugins are equal. It is business logic that is triggered by an event. For plugins the events are already defined before deployment, for workflows you can configure the events after deployment.

For me a project (dll) a deployment unit and if you take this to the 'extreme', I just ended up in combining everything into one project:

When you combine workflows and plugins into one project (dll), then you also get additional benefits:

1. You don't need a separate project for early-bound types. You can generate them inside the same project. This also applies for those 'Helper' libs.
2. If you don't need other references, then ILMerge is not needed anymore, which makes the build simpler.
3. Maintainability is easier, because at least 3 projects are now merged into 1 project. Easier for the developers, less risk when deploying and ALM/DevOps is simplified. Especially for solutions that have all kind of Azure parts (=more complex), making things easier helps.
4. Performance improvement within Dynamics365 / PowerApps (see https://docs.microsoft.com/en-us/powerapps/developer/common-data-service/best-practices/business-logic/optimize-assembly-development).

[magesoe]

Great arguments, can't say when we will look into the issue, PR's are helpful.

You will still need a separate project for testing, which means your early-bound types should be shared somehow. A great way is to use shared code projects instead, which also removes the need for ILMerge. However, you will need ILMerge in some cases, where you depend on some third-party authentication context.

You deploy solutions, not DLL's, so I can't see why it would make deployment significantly easier.

Great insights though

[RemyDuijkeren]

Would like to do a PR, but I don't know any F#

[TomMalow]

I think we have found a solution. PluginType has a boolean field "isworkflowactivity" that is populated by CRM when a plugintype is registered. We just have to apply an extra filter in pluginsync and workflow sync so that we only work on plugintypes related to the relevant sync.

Does that sound like a solution for you? You still have to call the two sync script independently. Does not have to be in a specific order as both script will have the new filter.

This solution is easy for us to implement so we should have a fix soon-ish. An optimistic estimate would be sometime next week.

[RemyDuijkeren]

I saw the field "isworkflowactivity" appearing, that also started my thinking about it. Sounds like a good and easy solution if it can be filtered out this way, because this seems the be the only problem.

[bo-stig-christensen]

@RemyDuijkeren : Just following up on this one. Was this ever implemented?

[RemyDuijkeren]

@bo-stig-christensen no it isn't :-)

tried yesterday if I could change it myself (assuming it should be easy to filter some result). Forked it and looked at it quickly but F# is so-not my language.

If it would be very easy for you Todo I would really appreciate it. But it isn't blocking me, I just have two separate projects. It is a nice-to-have.