Dynamics 365 Plugin Registration Tool Download

[Mireille Kreines]

Thisarticle demonstrates using Visual Studio to write the plug-in and build the assembly. However, you could use your favorite editor for coding and use MSBuild to build the assembly. In either case, you must use the Plug-in Registration tool to register the plug-in with Dataverse.

Alternately, you can use Power Platform CLI to quickly create a new project with boilerplate plug-in code using the command pac plugin init. You would still use the Plug-in Registration tool to register the plug-in with Dataverse.

Another alternative is to use the Power Platform Tools extension as described here: Create and register a plug-in package using Visual Studio. In this case, the extension can create and register the plug-in so the Plug-in Registration Tool isn't needed.

Adding the Microsoft.CrmSdk.CoreAssemblies NuGet package will include these assemblies in the build folder for your assembly, but you will not upload these assemblies with the assembly that includes your logic. These assemblies are already present in the sandbox runtime.

Do not include any other NuGet packages or assemblies to the build folder of your project. You cannot include these assemblies when you register the assembly with your logic. You cannot assume that the assemblies other than those included in the Microsoft.CrmSdk.CoreAssemblies NuGet package will be present on the server and compatible with your code.

Build the assembly using Debug configuration because you will use the Plug-in Profiler to debug it in a later tutorial. Before you include a plug-in with your solution, you should build it using the release configuration.

If you are connecting using a Microsoft account other than one you are currently using, click Show Advanced and enter your credentials. Otherwise, leave Sign-in as current user selected.

Other options for isolation mode and location apply to on-premises Dynamics 365 deployments. For the location, you can specify the D365 server's database, the server's local storage (disk), or the server's Global Assembly Cache. For more information, see Plug-in storage.

At this point the assembly and steps are part of the system Default Solution. When creating a production plug-in, you would add them to the unmanaged solution that you will distribute. These steps are not included in this tutorial. For more information, see Add your assembly to a solution and Add step to solution .

Because we are working with an asynchronous plug-in, the operation to create the task occurs after the account is created. Usually, the task creation happens immediately, but if it doesn't you may still be able to view the system job in the queue waiting to be applied. This step registration used the Delete AsyncOperation if StatusCode = Successful option, which is a best practice. This means as soon as the system job completes successfully, you'll not be able to view the system job data unless you re-register the plug-in with the Delete AsyncOperation if StatusCode = Successful option unselected.

To see the details, it's easier to query this data using the Web API in your browser using the following query with the plugintracelog EntityType, using the typename property to filter results in the messageblock property based on the name of the plug-in class.

I registered a plugin assembly using the SDK Plugin registration tool. I am trying to add a step but cant see any of my custom entities in the Primary Entity field. Am I missing something here? It is a trial instance of CRM Online and I am logging into the default organization.

I am unable to register a plugin assembly using the plugin registration tool for Dynamics 365. This is due to the Tool Resizing/Screen resolution issue on my laptop. I'm using a Win 10 laptop with 1366x768 resolution. The plugin registration tool buttons are out of the screen boundaries (bottom). I had no luck trying to use the 'Tab' key to control the buttons. The registration tool won't reduce in size beyond a certain point. Same problem with other versions

Use the registration tool that is available in the XrmToolbox. It's a much older version, before the tool was rebuilt with WPF. I know it will allow you to at least register a plugin in a 2013/2015/2016 org.

Today I checked the Dynamics CRM forum to answer some of the questions there. One of the question that I tried to answer was regarding the plugin registration tool. The screen shot that uploaded by the question shows different UI of plugin registration tool that I usually use.

In late July, Microsoft announced the preview of Dependent Assemblies, which would allow the ability to register individual assemblies, and upload a nuget package that contains both the plugin assembly and the dependent assembly. Previously, the only way this was available was the use of the ILMerge tool to manually merge dependent assemblies.

The first thing that is needed is to get the latest version of the latest versions of Microsoft Power Platform CLI (requires version 1.17 or later) and the Plug-in Registration Tool (requires version 9.1.0.155 or later). You will also need to use Visual Studio 2019 or later (note that the Power Platform Tools for Visual Studio do not currently work on Visual Studio 2022).

Once you have finished installing both the CLI and the PRT, you can go ahead and start creating your new project.

First create a directory to host your plugin and related file (using File Explorer).

We can now go ahead and build the project. Once we build the project, if you navigate to the bin/Debug folder you will see a nuget package with the same name as the Package that you created. This package will include your plugin code as well as the nuget package that we added to the project previously. The name will be similar to SamplePlugin.1.0.0.nukpg. The next steps are to install the package using the Plug-in Registration tool.

This option allows us the import and register a Nuget package as a plug-in package. When you click on the Register New Package option, the PRT will open a new dialog that will allow selection of the plug-in package that we created. The screenshot below shows this dialog. Note that you have the option here to import the package into an existing solution or create a new solution.

At this point in time, you can go ahead and add any required steps to the assembly, or if you need to make changes or remove the plugin, you can Update the Plugin package or remove the Plugin package.

My name is Aric Levin, and I have been a technology evangelist for over 20 years. I am an expert in the areas of Software Development and Architecture, and over the past 13 years, my focus has been on Microsoft Dynamics CRM/365.

I graduated in 2004 with a degree in Computer Science, while working full time in various technology related position. In 2005, while working as Chief Technologist for a Marketing Company, I was introduced to Dynamics CRM (version 3), and soon after started working with Microsoft Dynamics CRM.

UPDATE 19/9/18: It has been fixed in 9.0.2.5 version of Plugin Registration Tool If you use 9.0 version of Plugin Registration Tool to update your assemblies in Dynamics 365 you may encounter the following exception:

This is considered an in-place upgrade. The older version of the assembly is removed when the solution containing the updated assembly is imported. Any pre-existing steps from the older solution are automatically changed to refer to the newer version of the assembly.

When an updated solution containing the revised assembly is imported, the assembly is considered a completely different assembly than the previous version of that assembly in the existing solution. Plug-in registration steps in the existing solution will continue to refer to the previous version of the assembly. If you want existing plug-in registration steps for the previous assembly to point to the revised assembly, you will need to use the Plug-in Registration tool to manually change the step configuration to refer to the revised assembly type. This should be done before exporting the updated assembly into a solution for later import.

Although you may not be able to connect due to TLS 1.2 restriction in the cloud environment. -ph/help/4077479/unable-to-connect-to-dynamics-365-online-version-9-0-using-sdk-tools There is a workaround. You can use a proxy to upgrade the version of TLS by a man in the middle. My favorite tool is for packet inspection is Fiddler 4 which supports TLS 1.2 and can be used for this:

Plugin registration tool (v.9) was working fine but I had to change the user account to deploy a plugin and tool started crashing. It was accepting my password, showing available CRM instances, and after I select the instance, without reporting any error it was crashing.

I m an IT consultant working in Melbourne Australia. I solve business problems using Microsoft technologies (Dynamics 365, Office 365, Azure, Flow, Power Apps, Power BI). I m involved in community activities and I blog at

I love to get connected with people working in IT, providing solutions or who just like Microsoft technologies. To get in touch please follow my blog, and connect through Linkedin, Twitter or Facebook

To debug the plugin we have to follow the following steps: Go to the environment where the plugin is registered and install the plugin profiler. After the installation, select the plugin step you want to debug and click on start profiling and in the dialog select ok. This will start saving the profile. Perform the step on which you have registered your plugin so that we can save that profile. In my case, creating the contact. Go to your visual studio plugin project and attach the debugger to the Plugin Registration Tool and put a breakpoint on a line from which you want to start your debugger.

Go to your plugin registration tool, select debug. After that select the profile on which you want to debug.

Then select the assembly of your plugin (.dll)

Click on start execution.

3a8082e126