{"id":233,"date":"2017-05-08T14:17:33","date_gmt":"2017-05-08T04:17:33","guid":{"rendered":"http:\/\/bakke.online\/?p=233"},"modified":"2017-05-08T14:17:33","modified_gmt":"2017-05-08T04:17:33","slug":"debugging-net-code-called-from-dynamics-ax","status":"publish","type":"post","link":"https:\/\/www.bakke.online\/index.php\/2017\/05\/08\/debugging-net-code-called-from-dynamics-ax\/","title":{"rendered":"Debugging .NET code called from Dynamics AX"},"content":{"rendered":"

From time to time it is necessary to develop custom .NET code and call it from Dynamics AX. \u00a0It could be that you already have the .NET code to do what you need and you don’t want to reimplement the functionality in X++, or what you are trying to do is too complex to do directly in X++.<\/p>\n

One common situation is where you need to write a wrapper around some operating system functionality or web service to expose a much simpler API to AX.<\/p>\n

This works, and AX has good support for calling .NET code through it’s .NET interop framework. \u00a0One thing that does become more complicated is debugging, but once you know how it is actually quite easy.<\/p>\n

<\/p>\n

Visual Studio<\/h3>\n

In order to debug .NET assemblies you will need Visual Studio. \u00a0If you’re developing your own .NET code you will most likely have this already, and the steps shown here should work with any recent version of Visual Studio. \u00a0I have done this with Visual Studio 2013 as well as 2015.<\/p>\n

Compiling your assembly<\/h3>\n

First of all, make sure you have selected a debug configuration and then compile your .NET assembly. \u00a0In your output folder you’ll find your DLL along with a PDB file. \u00a0These need to be copied to your Dynamics AX client bin folder, typically located at C:\\Program Files (x86)\\Microsoft Dynamics AX\\60\\Client\\bin.<\/p>\n

If your project has references to other assemblies, such as Microsoft Exchange Managed API or similar, the required DLLs and their PDB files will also be copied to your output folder. \u00a0In that case, make sure that these are also copied to the AX client folder.\"\"<\/a><\/p>\n

For a redeployment, you would only need to copy the assembly DLL and PDB for what has actually changed. \u00a0The referenced Exchange API assemblies would not have changed and can be ignored when you redeploy.<\/p>\n

Adding reference and code to the AX side<\/h3>\n

In the AX development environment, add a reference to your assembly. \u00a0Right-click on the References node in the AOT and select Add reference:<\/p>\n

\"\"<\/a><\/p>\n

Click Browse and select the DLL you copied to the AX client folder. \u00a0The assembly will show up in the bottom half of the form:<\/p>\n

\"\"<\/a><\/p>\n

It is not necessary to add references to assemblies referenced by your DLL. \u00a0The .NET runtime will take care of that automatically, the DLLs just need to be in the same folder or in the Global Assembly Cache.<\/p>\n

After you have done this, restart the AX client.<\/p>\n

Write some code to test the assembly<\/h3>\n

For this demonstration, let’s just write a small job to test the assembly:<\/p>\n

static void<\/strong><\/span> EB_TestDebugger( Args _args )\n{\n  AXExchangeInterface.ExchangeInterface exchangeInterface;\n  int<\/strong>      <\/span>numEmails;\n  int<\/strong>      <\/span>i;\n  Filename tempFileName;\n\n  new<\/strong> <\/span>InteropPermission( InteropKind::ClrInterop ).assert();\n\n  tempFileName      = WinAPI::getTempFilename( WinAPI::getTempPath(), \"AXPDF\"<\/span> );\n  exchangeInterface = new<\/strong> <\/span>AXExchangeInterface.ExchangeInterface( \"user@domain.com\"<\/span> );\n  numEmails         = exchangeInterface.LoadEmails();\n\n  for<\/strong><\/span>( i = 0<\/strong><\/span>; i < numEmails; i++ ) \/\/ .NET is using zero-based indexes<\/em><\/span>\n  {\n    if<\/strong><\/span>( exchangeInterface.GetAttachment( i, tempFileName ) )\n    {\n      \/\/ Do something with it<\/em><\/span>\n    }\n  }\n\n  CodeAccessPermission::revertAssert();\n}<\/pre>\n
Nothing fancy, just asserting CLR interop permissions, creating a CLR object from a class in the assembly, then call some simple API methods on it before we revert the CLR interop permissions assert.<\/p>\n
Don’t run the job just yet. \u00a0We’ll need to attach the debugger first, but before that I strongly recommend to run with only a single instance of the Dynamics AX client. \u00a0It will make it a lot easier to select the correct process to attach to.<\/p>\n
Attaching the debugger<\/h3>\n
Back in Visual Studio, with your .NET assembly project open, set breakpoints in your code where you want them. \u00a0When you are ready to start debugging, click DEBUG and then Attach to Process.<\/p>\n
\"\"<\/a><\/p>\n
In the form that opens, find and select your Dynamics AX client process. \u00a0It will be named ax32.exe.<\/p>\n
\"\"<\/a><\/p>\n
It is possible to use Visual Studio to debug processes running on remote computers as well, but let’s leave that complexity out of it for now. \u00a0Click the Attach button to attach to the AX client process.<\/p>\n
Have a look at the breakpoints you set earlier. \u00a0If they appear red like normal, everything is good and debugging should work well. \u00a0If they are just a red ring with white center, the AX client has not loaded symbols for your assembly which usually means that the assembly has not been loaded, either.<\/p>\n
Good:\u00a0\"\"<\/a>Bad:\"\"<\/a><\/p>\n
If the breakpoints are not lighting up correctly, detach from the AX client process again (Don’t choose terminate…) and start troubleshooting what could be wrong:<\/p>\n