Do you want to deploy dependent assemblies part of the same plugin? Microsoft now provides a supported way to do so, and it’s easier than you think! In fact, you can do it in less than 90 seconds 😉
Background
A bit of background… For many years building Dynamics and Dataverse plugins that span across multiple assemblies has been a source of frustration and a challenge. Back in the on-premise days, we used to GAC dependent assemblies. Then came the online area where we could only deploy one assembly per plugin collection which forced us to use ILMerge. ILMerge was never officially supported by Microsoft but we did it anyway because it worked. Microsoft doesn’t recommend this approach, but they also don’t stop you from using it, even with the introduction of dependent assemblies. We always lived in the fear that one day we will open a support ticket and Microsoft would flag our customization as unsupported.
Those days are over now that Microsoft provides a fully supported way of bundling dependent assemblies associated with a plugin… and it’s easy to implement!
Prerequisites
Assuming you know how to build and deploy a normal plugin (you have Visual Studio installed etc.) you will also need the following – at least for this version of creating the package:
- PAC CLI version 1.17 or higher.
- Plugin Registration Tool version 9.1.0.155 or higher.
There is also another way of creating and deploying this package using the Power Platform Tool for Visual Studio but I’ll cover that in a different post.
This video demonstrates all the steps required to implement a package edited to fit in less than 90 seconds. The edited parts are related to waiting for things to load and my slow typing. I cover the step by step in the rest of this post.
Creating the package
To create the package we will follow the official documentation and start by calling the PAC CLI within the folder where we want to create the project.
pac plugin init
This will create a standalone project using the folder’s name with all the set up required to generate a NuGet package at build.
In the video, I then continue by adding some new local projects and sign them. You can also add 3rd party assemblies using NuGet package manager.
About signing
The documentation states that signing is not required. But it also states that if one of your assemblies is signed then all your assemblies needs to be signed. By default, the generated projects created by the PAC CLI is signed so I signed my dependet package as well.
Building
I continue in the video by building the solution using a keyboard shortcut. This then generates a NuGet package under the bin/Debug or bin/Release folder. The NuGet package also includes all the required assemblies. It omits assemblies the ones that are assumed to be deployed to the servers (e.g. Microsoft.CrmSdk.CoreAssemblies etc.).
Registration
If you are using the latest plugin registration tool you will notice that you can now register a package. Follow the steps in the video to deploy the NuGet package. The rest of the plugin registration remains the same as the good old plugin registration we are using to for single assemblies.
Unregister
You also have a new view to visualize the different package deployed. In order to unregister your package it’s easiest to switch to the package view and remove it from there.
It works!
Simple steps. Nothing magic… and it works!
Here is some official documentation:
First time mentioned https://bit.ly/dawave1
Latest wave mention https://bit.ly/dawave2
Official documentation https://bit.ly/dataverseda
ILMerge is also mentioned in the documentation. If it’s already working for you and it’s too difficult to change to the new approach you can keep your assemblies as they were, just remember this is an unsupported way and that there is a better alternative out there.