Friday, May 13, 2011

Debugging managed code in AX 2012

Since a lot of X++ code is now executed in CLR there should be a possibility to debug it. The standard AX debugger cannot help here since it is capable of debugging interpreted code only. However, Visual Studio 2010 can do the job.
There are few steps needed to be able to debug managed X++ execution using VS:
  1. Breakpoints should be enabled on server (in AOS configuration).
  2. Visual Studio should be started with elevated permissions (run as administrator).
  3. Visual Studio should be attached to Ax32Serv.exe process (AOS process).

After that you can locate the source code and place the breakpoint. This can be done either using Application Explorer, or by opening .xpp source file directly from the [AX server path]\bin\XppIL\Source folder. Each method of each class or table has a separate .xpp file that is named [ClassName].[MethodName].xpp.

And that’s it. Now the debugging will happen is visual studio. Call stack, watches, etc. are also available.
Labels: , , , ,

8 comments:

  1. Thanks for this post, that is really interesting! :)

    ReplyDelete

  2. Hi, thanks for your post. I have tried, but when I set the break point at the source code, when i put my mouse over the breakpoint, it shows"The breakpoint will not currently be hit. No symbols have been loaded for this document."

    Can you help me how i can solve it?

    thanks !

    Jie

    ReplyDelete

  3. Hi, Thanks for the post. It worked. So it looks like we can not do the debugging from client machine ?

    ReplyDelete

  4. Hi
    What do I need to do to come around this message: "The breakpoint will not currently be hit. No symbols have been loaded for this document."
    It works sometimes if the AOS is restarted.
    But with hotswap enabled I thought this should be avoidable!

    spc

    ReplyDelete
    Replies

    1. Same problem here. Any solution?

      Delete

    2. Same problem here. Any solution?

      Delete

    3. But is it just a message or you're not hitting the breakpoint actually?
      The message can appear because CLR lazy loads assemblies, so it may be not loaded at the time you set the breakpoint but it will be loaded when the execution will come to you method and the breakpoint will be hit.

      Delete

    4. So it means, this message is kind of ok if you still hitting this breakpoint.

      Delete

Subscribe to: Post Comments (Atom)