0

I'm trying to learn how to debug between Dynamics (AX 2012 R3) and Visual Studio. But for some reason I am unable to trigger any breakpoints in Visual Studio.

I've searched far and wide for more than a day and tried at least the following things (I've honestly lost track):

  • Ensured I'm compiling as DEBUG
  • Ensured DEBUG and TRACE constants are defined.
  • Unchecked "Enable Just My Code"
  • Unchecked "Require source files to exactly match the original version"
  • Checked "Use Managed Compatibility Mode"
  • Compiled, Cleaned, Rebuilt
  • Deleted the dll from my user's AppData VSAssemblies folder
  • Manually attached Visual Studio to AX32.exe
  • Let Visual Studio open it's own AX32.exe instance on debugging
  • Run Visual Studio with elevated permissions.
  • Compiled the project in the AOT
  • Not compiled the project in the AOT
  • Removed and re-added the project to the AOT

My setup is like follows:

  • Dynamics AX 2012 R3
  • Visual Studio 2013
  • Windows 10 client
  • AOS on a server (not locally)

I don't know what more to try. What examples and solutions I find either don't have my problem or apply to other versions and reference settings I don't have. Or I tried them and it didn't help...

EDIT 1: I have been able to piece together a little more. Apparently the "deploy" function from Visual Studio does absolutely nothing. In order for my project (and dependent X++ code) to work I need to:

  1. Open AX client
  2. Compile the project there (this puts the DLL into the server folder)
  3. Restart the AX client (this puts the DLL into the client folder)
  4. Compile all dependent changes

If I then want to be able to debug it all I need to overwrite both locations with my locally compiled dll+pdb files.

This, to me does not seem like a good way to do things. What am I missing here?

Alex Kwitny
  • 11,211
  • 2
  • 49
  • 71
Kempeth
  • 1,856
  • 2
  • 22
  • 37

2 Answers2

1

You have tons of steps, but I just spotted one glaringly wrong one.

Manually attached Visual Studio to AX32.exe

That's the client, you need to attach to the server piece AX32Serv.exe. There is a checkbox that says "Show all processes" or something and you need to do it from the AOS.

See: https://msdn.microsoft.com/en-us/library/gg860898.aspx

Alex Kwitny
  • 11,211
  • 2
  • 49
  • 71
  • Doesn't this depend on what code I am executing? Like where the X++ code that calls my .NET stuff does execute? – Kempeth Apr 18 '17 at 06:07
  • No, I don't believe so. I think if you attach to the server and the code is executing on the client, it somehow handles that. Have you tried it? The documentation says to connect to the server piece and I've never heard of anyone connecting to the client for any reason. – Alex Kwitny Apr 18 '17 at 16:12
  • I'll try it. That would make things much easier. The training material I'm working with clearly instructs attaching to the client. But they have been wrong before... – Kempeth Apr 19 '17 at 06:53
  • Well I think Visual Studio is mainly for debugging the managed code. You are using the AX MorphX debugger too right? – Alex Kwitny Apr 19 '17 at 14:55
  • I am using that too, Yes. – Kempeth Apr 20 '17 at 05:53
  • 2
    It does depend on which process you want to debug. If you want to debug a DLL loaded to the client process, attaching the debugger to a completely different process on a (potentially) different computer wouldn't succeed. But if you want to debug CIL generated from X++, it exists and executes only on server. I used VS attached to a client when I was developing custom WPF controls, for example. – Martin Dráb May 21 '17 at 06:08
0

I can confirm your procedure in "Edit 1" is how I have been having to get Visual Studio to recognize the breakpoints. It took me a long time to figure it out. I wish I came here first. I agree, this workaround should not be the norm. It seems like there should be a mechanism to deploy the PDB file along with the DLL when the project is compiled in the AOT, but I have not been able to find that.

Timothy Ott
  • 1
  • 1
    Please do not answer with a comment/question. Understandably, your rep is too low to comment, but that still does not mean answers should be used to make comments as an alternative. It would be preferable if you deleted this. – Gerhard Jun 28 '22 at 13:02