Introduction

Consider the situation where a developer (Dustin) has updated the plugin assembly Contoso.Common.Plugins.dll (Figure 1) on the development server. Dustin then starts testing the code updates and hasn’t yet checked those code updates into the code repository.

Now consider that another developer (Leon) wants to update the same plugin assembly with their code updates. Since Dustin’s code hasn’t been checked into the repository, when Leon’ updates the assembly (using the Plugin Registration Tool), Dustin’s code will be removed.

To get around this issue, Dustin could create a temporary plugin assembly e.g. Contoso.Common.Plugins.Dustin.dll in order to test his code. That way, Dustin won’t be impacted by other developers.

In the example below, a custom api called DocumentApi exists in the plugin assembly Contoso.Common.Plugins. This will also be added to the temporary assembly Contoso.Common.Plugins.Dustin. That way, the developer can make updates to the custom api and not be impacted by other developers who are also making updates to the assembly

Note, this is an alternative method to test plugins https://dustinminer.com/2023/03/16/creating-a-plugin-and-unit-testing-it-with-fakexrmeasy/

Steps

A copy of the folder Contoso.Common.Plugins project is made and renamed Contoso.Common.Plugins.Dustin (Figure 2)

The temporary plugin project is added to the solution (Figure 3)

The name of the temporary plugin project is updated (Figure 4 & 5)

The plugin (Contoso.Common.Plugins.Dustin.dll) is registered using the Plugin Registration Tool (Figure 1)

The ‘Plugin Type’ is updated to to point to the temporary plugin assembly (Figures 6 & 7)

The custom api runing in the temporary plugin assembly can now be tested (Figure 8)