“Only those who dare to fail greatly can ever achieve greatly.”
When I was a junior CRM Developer I couldn’t get remote debugging working, Visual studio wouldn’t attach, port problems etc. I gave up because I need to resolve the problem.
Until I have done something I’m not sure I can get it working.
The mind makes unknowns scarier; it exaggerates and focuses on worse case scenario’s. Like visiting somewhere you have never been before such as you first day at school/university. The location seems bigger and shrinks in size with familiarity.
Remote debugging is frustrating because to find out why a customization is erroring you need to debug it.
One day I came to work determined to get remote debugging working and after half a day of trying I got it working.
When using a tool or functionality for the first time, you are outside of your comfort zone (How to cope when you are out of your Developer comfort zone)
Why we need a CRM Developer toolkit
It’s important the CRM developer toolkit is updated and works with CRM 2015/Visual studio 2015. The CRM developer toolkit makes it easier new CRM developers to write, update and deploy plug-ins. We don’t want barriers for new CRM developers we want to encourage them to join the CRM development community.
- Where is the CRM Developer toolkit for CRM 2015?
- CRM Developer Toolkit Alternatives
- Getting the CRM Developer toolkit working with Visual Studio 2013
Remote debugging considerations
Remote debugging has some drawbacks, if the plugins has isolation mode = “none” you use the CRM async service, W3p.exe. This stops the CRM server processing system jobs, other users have to wait until you have finished debugging. This is frustrating for other developers because it stops them using CRM.
A better alternative is to test your code using unit tests or console app if I want to call it with data in CRM, this has no effect on other developers and units tests can be rerun by any developer.
Most scenario’s you can test your logic without using the remote debugger, Why CRM Developers should unit test their code
I wrote about remote debugging for CRM 2011 before
If you experience problems setting up the remote debugger, try this blog
Learn Remote debugging before you need it
It’s better to learn a process, new functionality before you use it for the first time on a project,
Make mistakes in practice, it’s a less stressful place to learn than on a live project
Get experience remote debugging before you need to use it.
Remote debugging can be a frustrating due to difficulties in setup and configuration.
Remote debugging is on for On Premise CRM only
You cannot remote debug CRM online.
To debug plugins deployed on CRM Online, you have these choices
The purpose of remote debugging is to test the logic. You can recreate the scenario from in dev by recreating the data. Remote debugging shouldn’t be the first tool when diagnosing a problem, it can affect performance and other developers
- Unit Test
- Console app and Test plugin code
- Plugin Registration tool
The debugging option work with CRM On Premise but you cannot use the remote debugger with CRM online.
You can unit test code and create a connection for IOrganisationService to your online CRM and pass and then run unit tests.
Create a console application, connect to your CRM online and test the code, mimicking the plugin.
Plugin Registration tool
The plugin registration tool can debug the code, it has the advantage of not freezing the whole server because it works with CRM on premise and CRM online.
Remote debugging steps
The process is the same for CRM 2011, CRM 2013 and CRM 2015 plugins. Custom Workflows are different, this blog post walks through the process – Debugging Workflow Custom Activities with Plugin Registration Tool
In this blog post I focus on using the remote debugger and a plugin
I’m using CRM Developer toolkit and running the remote debugger, you can run it as a service which runs all the time (called Remote Debugger) or you can run it as application. which starts when you need it.
Running as a service is it’s always running and can be set to auto start on server reboots.
The downside is the remote debugger service will always be running and taking a bit of server memory/processing (although not much). You can stop the service if you need.
Developers should use remote debugging in a development environment.
Build the plugin
Copy the plugin/custom workflow .dll and .PDB files to the CRM server directory
C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly
If you haven’t installed CRM on the C drive then you need to look for it on another drive
The DLL’s and PDB copied to the server must contain the code you want to debug in Visual Studio. If the code on your local machine is different from the deployed plugin you won’t be able to debug
Important – Copy the .dll and .PDB files to C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly
Important 2 – Any dependencies in your plugins (dll‘s) which are not in the GAC need to be copied to the server as well.
I copied the PDB files here
C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly
What is a PDB file?
You may be wondering what a PDB file is, my knowledge of them is you need them for debugging and they contain the code you have written where as the DLL has the compiled code.
Wiki describes PDB file as
PDB stands for Program Database, a proprietary file format (developed by Microsoft) for storing debugging information about a program (or, commonly, program modules such as a DLL or EXE). PDB files commonly have a .pdb extension. A PDB file is typically created from source files during compilation. It stores a list of all symbols in a module with their addresses and possibly the name of the file and the line on which the symbol was declared. This symbol information is not stored in the module itself, because it takes up a lot of space.
A PDB is needed for debugging, it isn’t needed when you deploy your plugins or custom workflows.
recap of steps
- Ensure the remote debugger is running as a service or application
- Build the plugin
- Deploy the plugin
- copy the DLL and PDB to the CRM server folder
- C:\Program Files\Microsoft Dynamics CRM\Server\bin\assembly
Attaching the process
You should be ready to attach Visual Studio to the process and wait for the code to be trigger and your visual studio breakpoint to be hit.
Set a breakpoint in the plugin, put the breakpoint at one of the first lines to avoid breakpoints not being hit because their code was either erroring or not being triggered.
Press the Attach button
Brings up this page, it will default to your local machine but you need to put in the name of the CRM server and the port used in the remote debugger.
If my port was 4016 and the CRM server was called CRM server.
Make sure you tick Show Processes from all users, if you don’t you won’t be able to see the CRM services because they are most likely run as a different user.
If you don’t know your port number, you can go to the CRM server, open the Remote Debugger to find the path of the application
click on msvsmon and it will error and tell you the port number you are using.
When you put in the correct CRM server and port number, the services running will be listed.
If you plugins are in the sandbox (Understanding Plugin sandbox mode) you need to attach the to the process Microsoft.CRM.Sandbox.WorkerProcess.
Usually there are multiple Microsoft.CRM.Sandbox.WorkerProcess. This is because you get one for each CRM web page. It’s difficult to work out which process is the process you want to debug, so I usually select all of the Sandbox WorkerProcesses to ensure I debug my process.
The final stage is to trigger the plugin and debug your plugin.