Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
RemyDuijkeren opened this issue Mar 3, 2020 · 8 comments
Open

Comments

@RemyDuijkeren
Copy link

RemyDuijkeren commented Mar 3, 2020

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.
image

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
Copy link
Collaborator

magesoe commented Mar 4, 2020

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
Copy link
Author

RemyDuijkeren commented Mar 4, 2020

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:
image

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
Copy link
Collaborator

magesoe commented Mar 4, 2020

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
Copy link
Author

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

@TomMalow
Copy link
Member

TomMalow commented Mar 16, 2020

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
Copy link
Author

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
Copy link
Member

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

@RemyDuijkeren
Copy link
Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants