NAV Team: RTC debugging - Dynamics CRM: Blogs

Blog bot · 05.03.2012, 20:17

Create a pageActivate debuggingDebugOther useful information when debugging

For this example we will be using Microsoft Dynamics NAV 2009 R2 and Microsoft Visual Studio 2010 Professional.

Create a page

To use as an example for debugging, let's create an empty page (for example 50000 RTCDebugTest) with a new action called “Messages”. In code of this action, we create two local variables:

Name

DataType

Subtype

Length

n

Integer

str

Text

30

And write the following code lines in “Messages - OnAction()”:

n := 21;

MESSAGE('%1', n);

str := 'Hello World!';

MESSAGE('%1', str);

Just to access the actions a little faster, we will change these properties of the action:

Promoted=Yes;

PromotedIsBig=Yes;

Image=Start;

Save and compile.

Activate debugginghttp://<br /> <br /> For this we nee... <br /> <br />Debugging

Now we open Visual Studio (right click and “Run as Administrator&rdquo

. Now we need to open the source code of our page, so we go to “File -> Open -> File” (Ctrl + O) and from all the generated .cs files we open the page that we have just created (50000 RTCDebugTest):

Now we can see our C/AL (commented) and its equivalent in C# for each line:

In this case we have set a breakpoint for the C# line that equals our C/AL “n := 21;”, by doing double click on the left margin or by going to “Debug -> Toggle Breakpoint”. The next step will be to go to “Tools -> Attach to Process” (Ctrl + Alt + P). From the list of processes we select our NAV service and click on “Attach” (if you can’t see the NAV service in the list, check that it is running, and mark “Show processes from all users”:

Now if we run the page on the RTC, and click on the “Messages” action:

We will see that Visual Studio will stop right on our breakpoint:

And we can continue to debug using F10 (Step Over) and F11 (Step Into):

This is all that you need to know in order to start debugging your RTC code. The following information contains important details and also extra information in case you need to debug a little deeper.

Other useful information when debugging

If we make a change in our page in NAV

In this case, after saving and compiling our page in the Classic Client and running the page again, Visual Studio will show us this message box indicating that the source code has changed and we if would like to Update it:

<a href="http://blogs.msdn.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-84-65/0042.9.jpg">

After accepting it, we will see the page code now reflects the changes we did to the page.

Variables

We can analyze the behavior of our variables during execution, either by setting the mouse over the variable that we are interested in:

Or by pinning it if we want to monitor its value through execution:

Or we can also add the variables that we would like to monitor to a “Watch” (double click over the variable, and drag it to the “Watch”:

We can also monitor our local variables in the “Locals” tab. In this example, we can see how our “str” or type Text in C/AL creates an object of type “NavText” in C#. For these cases in which our variables are objects, we can also see the values of any attributes of the class, like for example “MaxLength”, which we had left by default in 30.

Breakpoints

In the breakpoints panel we can see all the breakpoints that we have defined (for this and other .cs):

Sometimes we might want to stop at a breakpoint only if a certain condition is true. For this we can create a conditional breakpoint by right clicking on the breakpoint and selecting “Condition…”, and we will see a window where we can set the condition:

In this case we set it to stop only when “n” is different than “2” (which obviously always happens, so it will always stop, but this is just a silly example). The conditions we set will all appear in the breakpoints panel marked with a white cross and with the condition.

Calls

In the Call Stack panel (Debug -> Windows -> Call Stack) we can see the calls that happened up to the breakpoint or line in which we have stopped. For example, if we modify the code of the page so that in “OnAction” we call a function “Funcion1” and from this one we call another function called “Funcion2”, and set a breakpoint on “Function2” we will get the following call stack:

Registers, Memory and Dissasembler

If for whatever reason we need to analyze at a lower level what is happening underneath, we can also check the state of the registers (Debug -> Windows -> Registers), where we will see in red any values which have changed in the last executed line:

Or check the value that was loaded in a certain memory address (Debug -> Windows -> Memory). You can also see the disassembly code (Debug -> Windows -> Disassembly) and debug from here instruction by instruction:

Juliet R. Moreiro Bockhop

Microsoft Dynamics NAV Support Engineer

“Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability or fitness for a particular purpose. This mail message assumes that you are familiar with the programming language that is being demonstrated and the tools that are used to create and debug procedures.”

Источник: http://feedproxy.google.com/~r/Micro...debugging.aspx