Power Platform Tidbits #6 – Plugins in single-project vs multi-project

Plugins has been and are an integral extension point in Dynamics and now Dataverse. They allow you to put logic close to the data. Logic that can be invoked at different stages of execution of an action (aka message).

When the number of plugins grows, you might be willing to separate them into different projects and even share common parts of logic through a project that referenced by other projects. This is the most common way of organizing code in almost any kind of application development. However when it comes to Plugin development for Dataverse, this is not the recommended way of development and for good reasons.

Benefits of single-project plugins

• Lower memory footprint
• Easier to manage, version-control and deploy. In other words the whole ALM becomes easier.
• Recommended by Microsoft in several official docs.
  • Write a plug-in (Microsoft Dataverse) – Power Apps | Microsoft Docs
  • Optimize custom assembly development – Power Apps | Microsoft Docs

In fact, Microsoft recommends that you consolidate all your plugins into one assembly until the size of the resulting assembly grows larger than 16MB. So far it seems that single-project is the only way to go, but there is a caveat here!

Benefits of multi-project plugins

When you are in a big project with multiple developers assigned to plugin development at the same time, the complexity of deployment and test will increase with the number of developers. Imagine each developer working on a new plugin (presumably each in a different git branch) and the test environment is shared. Every time a new version of the assembly is deployed, it might contain only one of the new plugins.

One solution is to give every developer an isolated environment, but it is not always possible due to the number of integrations required and many other complications that comes with provisioning a new environment.

Another solution is to put in place a better discipline around your branching and deployment strategy. For example, you can ask developers to communicate with each other before deployment and cherry-pick other plugins into their own branch to make sure all the latest plugins are included in the deployment. This would work, but it is prone to human error (what isn’t 😏). So let’s summarize. Whenever you need to deploy a new plugin for testing:

• Try to manage requirement in such way to reduce the number of plugins in development at any given time.
• Put each plugin in a dedicated branch.
• Communicate before each deployment.
• Cherry-pick from other branches, anything that needs to be included in deployment.
• Implement unit-testing in your plugins to reduce the number of deployment required.

This last one (i.e. unit testing) can substantially reduce the number of deployment, increase quality and save precious time. The first one is important too.

Is there a better way?

There isn’t, or is there? 😑 Ok I will tell you. If the above does not suit for some reason. There is another solution that might help you. In other words, if you tried the above and you are still facing issues, or if you are avoiding single-project approach due to the issues you have faced, there might be a solution for you.

Visual Studio has a feature called linked files. This feature is very easy to use and allows you add links to files in you project without physically copying the file to your projects. I have always used this approach in SSIS development to target multiple versions of SSIS without duplicating the project. But how can we benefit from it in our plugins?

Imagine you are developing several plugins and each developer is working on a plugin (or more). You still put all your plugins in a single project and follow the same branching strategy, but when a developer needs to deploy the new plugin he/she can still create a new project and add all the files required as links into that project, deploy and test as needed. You can cleanup and remove that project in future before merging back to the main branch. The following demonstrates a situation when a developer is working on a LeadQualification plugin in a fancy project.

Fancy.Plugins:
- PluginBase.cs <──────────────╮
- LeadQualificationPlugin.cs <─│─╮
- NamingPlugin.cs              │ │
- ConnectionPlugin.cs          │ │
- ...                          │ │
                               │ │
Fancy.Lead:                    │ │
+ PluginBase.cs ─────────────────╯
+ LeadQualification.cs ────────╯

As you have notices Fancy.Lead project is just an empty project with two links to the main project, but when you compile, it will give you Fancy.Lead.dll in addition to Fancy.Plugins.dll that means you can deploy and test this smaller assembly TEMPORARILY until you are ready to merge it to the main branch.

To create those links you will need to simply hold down Ctrl + Shift while you drag and drop the file from the Fancy.Plugins project to the Fancy.Lead project. In fact if you have ever made shortcuts to files in Windows, this is pretty similar.