Is there are more efficient way of publishing/debugging Dynamics CRM 365 Plugins?

Question

I have been tasked with bringing our 2008 CRM server into the modern age of Microsoft Dynamics 365 on-premises. I have got a plugin working and java script which is my first task and debugging/remote debug is working too. I can also make changes to the DLL and the changes work. However I am really concerned with how long winded the process to publish the DLL to the server is and wondered if am missing something. Watched quite a few videos, googled a lot but everyone seems to cover getting it working and that's it.

I note during Registration there is an option to select 'Disk' for the location of the DLL but this just crashes when i select it? so I am having to select 'Database'

Initial setup:

• Build the plugin that adds a note 'A'
• Copy the DLLs from bin\Debug onto server bin\assembly folder.
• register plugin as Sandbox/Database
• test and it works.

Currently my development workflow is:

• modify the plugin code slightly to show 'B' instead of 'A'
• rebuild the DLLs.
• Copy the DLLs from bin\Debug to server bin\assembly folder.
• test and it still shows 'A'

The ONLY way I have been able to get this working and it seems there must be an easier way:

• rebuild the DLL's
• Copy the DLLs from bin\Debug to server bin\assembly folder.
• Open the registration
• locate the DLL again
• Tick the plugin selection boxes
• click update selected plugins
• test and it shows 'B'

This seems a real PIA if you need to rapidly change rebuild test which I suspect I will need to.

Is there an easier way?

Answer 1

Plugin publishing and debugging can be a challenge for sure.

As far as publishing goes, I use the commercial 3rd Party Visual Studio extension XrmToolkit (no affiliation), which is not to be confused with the wildly popular community-supported XrmToolbox app.

XrmToolkit enables you to configure, build, and publish a plugin directly from Visual Studio. This greatly streamlines the process of publishing updates.

Microsoft used to have a Developer Extensions tool, and Jason Lattimer had one too, but I'm not sure if either of those are in active development anymore.

Another technique that I generally employ is to put the plugin code into a Visual Studio Shared Project, which I reference from both the plugin project and a Console App. I use the Console App to develop and debug before publishing the plugin. After the plugin goes live, I'll continue using the Console App to troubleshoot or build enhancements.

For Example:

///Shared Project
public class MyPluginApp
{
    private IOrganizationService svc;
    public MyPluginApp(IOrganizationService svc)
    {
        this.svc = svc;
    }

    public void Run(Account target)
    {
        //do stuff with the Target
    }
}

////Plugin
public void Execute()
{
    var app = new MyPluginApp(context.Service);
    app.Run(context.Target);
}

///Console App
public static void Main()
{
    var svc = new CrmServiceClient(connectionString);
    var target = getLastTouchedAccount(svc);
    var app = new MyPluginApp(svc); 
    app.Run(target);
}

Please also see this answer.

Answer 2

Whilst the method I am using above is workable its downright painful and prone to mistakes. I found that restarting the IIS server also works but navigating to and restarting it is really not a viable option.

I found that there used to be a developers tool as mentioned by Aron called 'Microsoft Dynamics 365 Developer Toolkit' which you can download from MS here

For Visual Studio 2017 you will need to edit the vsix:

• Extract with 7Zip or rename as zip and extract to a folder.
• in the folder you will find extension.vsixmanifest
• edit the file and replace the lines

InstallationTarget Version="[11.0,14.0]"

with:

InstallationTarget Version="[11.0,15.0]"

• this tells the manifest to allow install on 2017
• rezip the contents of the folder (NOT the folder)
• rename the zipped file as .vsix
• install the vsix
• ignore the warning and finish installing.

You should now have a new Dynamics CRM section in your New Project section of VS2017.

You will need to go into 'Tools > Options > Dynamics 365 Development Toolkit > Tool Paths' and set the path to your CRMSDK bin and Tools/PluginRegistrationTool folder.

To create a new project:

• New Project
• Select the "New Visual Studio Solution Template for Dynamics 365"

To add a new Account entity for example:

• VS2017 > CRM Explorer
• Right click Account > Create Plug-in

Now unless i have forgotten something when you Right click the 'Package' and choose Deploy it will deploy to your CRM server ;)

Regards, DaveC

tip 1: The CRM SDK pointed to by our 365 server actually pointed to the 2015 SDK from microsoft. Caused some consternation on my behalf as the toolkit requires 8.0 upwards ;)

Answer 3

That's the dev workflow I used to do many years ago involving manual deployment and testing of plugins. Nowadays I use a much more modern and efficiet way of developing and testing plugins using TDD (Test Driven Development).

Traditional manual workflow involves:

• 1) Make changes to plugin
• 2) Deploy plugin via Plug Registration or other VS extensions
• 3) Test plugin manually in the target environment / attach remote debugger / profiler
• 4) Repeat

That's a very time consuming workflow.

With a more automated dev workflow it becomes instead:

• 1) Make changes to plugin
• 2) Debug / test locally
• 3) Repeat
• 4) Push your changes, and let the CI trigger build and release your plugin

Or if following TDD strictly:

• 1) Add / update any necessary unit tests based on the requirements, this will cause your plugins to fail, since that plugin doesn't have an implementation logic that validates those requirements yet
• 2) Update your plugin code so the unit tests pass
• 3) Refactor your code with confidence (making sure unit tests still pass)
• 4) Push your changes
• 5) Let the CI build and release automation trigger

The main difference is that with the TDD approach, your dev & test feedback loop is much more quicker, and you only (usually) need a single deployment step at the end, which can also be automated.

You can also make use of existing open source frameworks that allows mocking most of the interfaces in the Microsoft SDK for you like FakeXrmEasy (which I'm the author of).

Hope this helps