#CRMVisualSchema – part 6: XrmToolBox development pitfalls and tricks

It has been almost two weeks since I released the Entity Relation Diagram Creator for XrmToolBox.  Over 10.000 people already downloaded the plug-in, and I received a fair deal of suggestions to improve the tool. In the weeks to come, my mission will be to process these suggestions (some very wild ideas popped up *yay*).

In the previous article I promised that I would share a number of pitfalls that I encountered while developing the plug-in. In this article I’ll describe what I encountered and I’ll give you some tips which will streamline your development efforts.

Always start with a clean project

The first pitfall I fell into was by starting in a windows DLL project that I later converted to a XrmToolBox plug-in project.

For me this resulted in a plug-in that was not recognized by the XRMToolBox. A way to avoid this frustrating experience is by adding the XrmToolBox extension to Visual Studio.

Extensions

After installing the extension, you will find a new project type named XrmToolBox plug-in (A restart of Visual Studio might be required).

New project

From here on you have a good starting point to get your plug-in to show in XrmToolBox (as all required references are in place).

Error: The service Microsoft.VisualStudio.Shell.
Interop.ISelectionContainer already exists

From time to time this error may occur while trying to open the plug-in control in the designer. You will not be able to edit your control visually until you resolved this error.

Wut?!!!

It turns out that the error is caused by non corresponding versions of  MscrmTools.Xrm.Connection and XrmToolBoxPackage. Verify in the NuGet Package manager if the versions are corresponding.
If not update both packages to the latest version. This error costed me an evening to comprehend.

Do not sign the assembly

As developer I find it a good practice to sign the assemblies I develop.
For those not familiar with signing assemblies. Signing is a mechanism that allows you to ensure the authenticity of an assembly. This way you can guarantee that an assembly hasn’t been tampered with and it indeed origins from you.
The consequence of this is that signed assemblies only can load signed assemblies. Hence, your assembly cannot load in the XrmToolBox as its libraries are not signed and you will be confronted with an error message.

Debugging can be time consuming

In an earlier post , I described a mechanism on how to debug your plug-in by attaching the debugger to the XrmToolBox process. This process was time consuming as it involved a number of manual steps. A far better way of debugging is this (described on the XrmToolBox wiki pages):

Open the plugin project properties and navigate to the tab “Build Events”

Debug1

In the post-build event add the following text:

if $(ConfigurationName) == Debug (
 IF NOT EXIST Plugins mkdir Plugins
 echo "press any key and hit enter"
 pause
 copy /Y JourneyIntoCrm.*.dll Plugins
 copy /Y JourneyIntoCrm.*.pdb Plugins
 )

This script ensures that a folder plugin is made within the project’s debug folder. The plugin assembly and debug information (pdb) is placed inside this folder. This is needed, because XrmToolbox only looks for plugins inside the plugins folder.

Navigate to the “Debug” tab. Instead of starting the project, we need to start the copy of the XrmToolbox that can be find inside the debug folder of the project.

We do this by selecting the “Start external program” option, then by selecting the XrmToolBox.exe in the project’s bin\debug folder.

Debug2

Now we are almost there…

In order to launch your plugin automatically, you need to specify in the start options section, the following command line parameters

/overridepath:
/plugin:[Some name for your plugin]
/connection:[Name of the connection you want to use]

the “.” behind the overridepath argument is not a typo! This “.” ensures that the XrmToolbox will look in its current execution path.

The advantage of using this mechanism is that every time I start the debugger, a new instance of XrmToolBox is launched , my plug-in is loaded automatically and that the toolbox connects to CRM. This saves a great amount of your precious time.

When running in debug mode, the debugger will kick in automatically when hitting any breakpoint.

Publish your plug-in to the XrmToolBox plug-in store

For publishing I followed the guidelines as described on the XrmToolbox wiki.

Before you are able to publish your plug-in on nuget, you need to obtain an API key. You can do this by registering an account on nuget.org. In nuget.org go to your account page (you do this by clicking on your username). Scroll down the page, there you’ll find an option to get an API key.

Nuget API key

I chose to use the Nuget Package Explorer which I downloaded from the Windows Store (windows 10 required). When you download the tool, you need to enter your API key before you can upload your package to nuget.

Nuget

Within the Nuget Package explorer app you need to specify your settings. There are a couple of important settings:

Tags:
This field has to start with “XrmToolBox Plugins”

Framework Depencies:
In this field you can specify what the minimum version of “XrmToolBox” should be (e.g. 1.2017.3.14)

Nuget explorer

Finally you need to add your plugin dll. In the right pane you need to specify a folder structure first. You can do this by right clicking the Lib node. Choose “Add .Net folder”, choose version 4.5.2.

Inside this folder I created a new folder (right click the net452 node) called “Plugins”. Inside the plugins folder, I added my plug-in assembly.

When all settings are made, click on the green checkmark on top of the window.  The solution will be presented as follows:

Nugetexplorer2

When you go the the File menu, you can choose the Publish option. The solution will be uploaded to nuget and will be visible after a short while in the XrmToolBox plug-ins store.

A big “Thank you”!

Overall, I was very impressed with the maturity of the XrmToolBox framework and the tooling available to get started. It allowed me to focus on my application without having to think of any of the infrastructural subjects (e.g. authentication, settings, connections, logging, application distribution etcetera).

Tanguy and Jonas (and those I didn’t mention) did a very impressive job! *kudos*

Leave a Reply

Your email address will not be published. Required fields are marked *