VisualStudio

This article will give you a step by step walk through of getting started with Dynamics 365 plugin development based on the Boruto Dataverse plugin framework. This article assume you are familar with Visual Studio. This guide has NOT been design for Visual Studio Code. Use the Community, Professional or Enterprise edition instead. The first one is free and can be downloaded from here:

Download visual studio

Micrisoft PAC Tool

You will also need the Microsoft PAC tool. This tool has a varity of tools to support the development of components for the Microsoft Dataverse platform. You will need to use the following two tools:

• pac init plugin
• pac model build

Download PAC msi package

PAC tool documentation

Setup Visual Studio project

The first thing to do is to open Visual Studio, and create a blank solution:

Provide a name and hit Create:

You now have an empty solution

Create a plugin library

These easy way to create a new plugin library is to use the Microsoft Power Apps PAC tool:

Read this:

OR...

Follow these simple instructions:

• Create a new folder in your solution folder, the name of the folder must be the name of your plugin, ex. MyPlugin
• Navigate into the folder from a command or powershell prompt
• Use the following command:
• pac plugin init [--skip-signing]
• [] indicates that the parameter is optional. Do NOT write the [] if you wish to ommit signing. If you plan to use unsigned assemblies in your plugin, you should use the skip-signing option.

Add newly created plugin library to your solution

After the plugin library has been created, you can add it to your solution.

• Right click on the top node (solution explore) and selected add > Existing Project
• Select the project file, created by the pac plugin init tool

You can delete the following files from the generated project:

• Plugin1.sc
• PluginBase.cs

Install the Boruto.Dataverse.Plugin package

Now go to Tools > NuGet

Navigate to the Browse tab, search for Boruto.Dataverse.Plugin. Select your library and click Install.

Select your plugin library in the right overview of projects in solution

Click Ok, and Accept in the popup's from the install project.

This installation has prepared both the needed Microsoft SDK tools for Dynamics 365 CE plugin development, and the tooles related to the Kipon.Solid framework.

Prepare strongly typed entities

The Boruto Dataverse Plugin framework does not provide any specialized way of generating early bound entities. Our recommendation is to use PAC Tool from Microsoft. You can find the documentation for the tool here.

Microsoft PAC Model Build tool

Be AWARE, the strongly typed datamodel DOES NOT NEED to be in same assembly as the plugin library. It is totally your choice. If you plan to create more than one library, or even plan to build Dataverse external tools, it might make sense to have the datamodel centralized, so any change in the datamodel will reflect in all your libraries.

If you create the strongly typed datamodel as a seperate library, make sure to initialize the project with the PAC plugin init tool. That way it is compatible with you plugin library and can be binded with you plugin library as a simple project reference. Even though it has been created as a plugin library, it can still be used as base library for tools using the Microsoft.PowerPlatform.Dataverse.Client.

Do NOT add the Microsoft.PowerPlatform.Dataverse.Client to the library where you plan to create you plugin code. That part of the code will get the IOrganizationService from the Dataverse Plugin infrastructure.

As a good rule of thump, it is a good idear to separate plugins that are dataproviders for virtual entities, from plugins that are services for your solution to support business logic. The reason for this is, that virtual entities has relations to providers and datasources than can be hard to get rid of, so by separating these two type of plugins it will be easer for your to wipe your "business-logic-plugin" on a need base, without having to remove datasource provider relations from your virtual entities.
These libraries can still share the same datamodel library.

Ready to go

You are ready to start build plugins. Try build your solution to make sure everything is in place. There should be no errors.

To start SOLID and stay SOLID, it is a good idea to get a basic structure for your code in place first. The Kipon.Solid framework has already giving you the first part of the structure, the "Entities" folder, where you should put code that are directly related to the Dynamics 365 CE entity model. All entity proxy classes has been generated as "partial" so you can add additional functionality by creating your own source files, and declare the same classes "again", with the partial flag in the class definition. Such extension of an entity should be placed in the Entities folder or in a substructure below the Entities folder depending on the size of your library

<

Beside the Entities folder, i recommend the following basic structure

• Models: Put cross entity interfaces and abstractions here. A model class in a Dynamics 365 plugin context is typicall an interface that defines the explicit hooks that are needed on the underlying entity to solve a task.
• Plugins: Here you should put your plugins. A plugin is the code that maps from an event to a service. If you plan to do a lot of plugins, create a folder for each entity and each action to listen for.
• ServiceAPI: Put all service interfaces here. Remember, to stay SOLID, all dependencies should rely on abstractions and interfaces, not on implementations. In this folder you define the interfaces that is needed to solve an assignment.
• Services: Projects developed with SOLID princips as foundation will often put interfaces in one assembly, while implementation in another. Due to the single assembly constrain on Dynamics 365 plugins, such helthy pattern is not an option, without adding messy deployment tool like ILMerge. Instead i place all service implementation in its own folder "Services". And then the project team need to follow the simple rule, that NOT DIRECT REFERECES to anything in the Services folder is allowed. The intention of the Services folder is to implement services defined by the ServiceAPI. Nothing else.