Dynamics 365 Debugging Tips

In today’s blog, we’re sharing some helpful hints for debugging Dynamics 365 code in Microsoft Visual Studio. The transition from the old MorphX debugger to the Visual Studio debugger brought many new features that can significantly assist with the debugging process. While attempting to document these new features, we began noticing (and thus compiled) a handful of helpful tips that we’ve come across while using Visual Studio to debug D365 code. They are:

  1. Breakpoint Window
  2. Conditional Breakpoints
  3. Pin Data Tips
  4. Out-of-Scope Objects
  5. View Return Values for Functions

Let’s look at each in detail…

1. Breakpoint Window

When working your way deeper into some complex code through several different objects, you inevitably end up with one or two breakpoints that are continuously getting hit. If you remove the breakpoint, you’ll have to come back and find it again, which is a hassle. So, instead of simply removing the breakpoint, try using the Breakpoints window, as shown below. This window will show all breakpoints you have set, but – and this is crucial – lets you disable them without unsetting them by simply removing the checkmark. To re-enable a breakpoint, simply check it again.

debugging

 

2. Conditional Breakpoints

It is often difficult or time-consuming to recreate a specific state for your current debugging session. Therefore, it is worth considering whether the use of conditional breakpoints can help. Right-click any breakpoint icon (the red balls) and choose Conditions from the menu. In the Breakpoint Settings window, you can choose to create a conditional expression in which the breakpoint will cause execution to stop only if the condition is true. You may also choose Hit count, where a breakpoint interrupts execution after a specified number of hits. Another available option is to create an action that logs a message to the output window.

debugging

 

3. Pin Data Tips

When debugging code, it’s helpful to be able to hover over a specific variable to see its current value. Even more helpful is to pin the data tip for the variable to give yourself quick access to its value. To pin the data tip, click the pin icon (thumbtack) while hovering over it. This will then automatically display the value without the need to hover over the variable. You can pin multiple variables.

debugging

 

4. Out-of-Scope Objects

When a variable goes out of scope in the Watch window, you may notice that it is then greyed out. You can track those out-of-scope variables by creating an Object ID for them in the Watch window. Here’s how:

debugging

 

debugging

 

5. View Return Values for Functions

In order to view return values for your functions, look at the functions that appear in the Autos window to see the return value for each function and make sure the function you are interested in has already executed:

debugging

Hopefully these tips and tricks are as helpful for you as they have been for us. They certainly can make debugging D365 code in Visual Studio a little bit easier. Don't forget to subscribe to our blog for more tips and tricks.

Happy debugging!

Debugging Your Plug-ins with the Plug-in Trace Log

Dynamics CRM developers can sometimes find it difficult to debug plug-ins for CRM Online since they don't have the luxury to debug them the same way they do it while writing plug-ins for CRM On-premises. Luckily, a new feature called Plug-in Trace Log was included with Dynamics CRM 2016, and in today's blog, we'll be showing you how you can debug your plug-ins using this new feature.

The Plug-in Trace Log feature saves trace log information, similar to the information you get when an asynchronous plug-in throws an exception, with the advantage that trace log information will be available even when the plug-in doesn't throw an exception. The steps needed to use this feature are broken down below.

1. Write the Plug-in

First, let's write a simple plug-in to test the new Plug-in Trace Log feature. Notice that in the sample code below, we added an instance of ITracingService to log information about the execution of the plug-in as well as logging some key values:

Plug-in Trace Log

2. Register the Plug-in

For this exercise, we will register this plug-in as follows:

Plug-in Trace Log

3. Enable Plug-in Trace Log

To enable the Plug-in Trace Log, first navigate to Mail > Settings > Administration.

Plug-in Trace Log

Once you're in the Administration section, click on System Settings.

Plug-in Trace Log

From here you can navigate to the Customization tab and select All for the Enable logging to plug-in trace log field. Then click OK.

Plug-in Trace Log

Test the Plug-in Trace Log

To test the Plug-in Trace Log, open any Account record, update the Fax Number and click on Save.

To check the Plug-in Trace Log entries, click on Main > Settings > Plug-in Trace Log.

Plug-in Trace Log

Double click on the entry created right after you updated the Account record. Keep in mind that the Trace Log record is created asynchronously, it might take a few seconds for the entry to show in the view.

Plug-in Trace Log

Once the Trace Log record opens you can investigate the information captured. This page will provides valuable information such as Type Name, Message Type, Primary Entity, Depth, Mode, etc.

Plug-in Trace Log

Scroll down and check the Message Block under the Execution tab. This is where you will find the trace log information you configured in your plug-in.

Plug-in Trace Log

IMPORTANT: only enable the Plug-in Trace Log feature if you are debugging or tweaking a plug-in. You don't want to create thousands of trace log records if you are not debugging a plug-in.

That's all for the blog today! You can learn more about the features included in Dynamics CRM 2016 by subscribing to our blog as well as viewing our numerous Webinars on Demand. The CRM Book has been updated to include content for Dynamics CRM 2016 as well, so make sure you check it out!

Happy CRM'ing!