One of the many things a developer should be doing frequently is debugging code. While Acumatica explains how to do this in some of the training material, it wasn’t until my first Hackathon that a fellow (now) Developer MVP, Joshua Van Hoesen, guided me to install remote debugger tools and leverage this ability.
My primary development environment involves the code and web server residing on a remote server. This tool opened the door to watching my code as it executed, thus identifying where values were stored or where my code would go off the rails.
In contrast, on my local machine, I would run Visual Studio as an Administrator and attach to my local IIS process for local debugging. I typically only use a local instance a few months out of the year as we prepare for upgrades or the annual Hackathon. However, today as I approach my 4th anniversary writing customizations for Acumatica, something profound (and now a bit obvious) hit me! Why not “remote debug” my local instance? Why do that, you might ask? Well, when I open Visual Studio as an administrator and then open files from the Code Repository, Visual Studio opens a new instance for the Code Repository files. This makes switching between standard and custom source code really annoying for me.
What is Remote Debugger?
In layman’s terms, Remote Debugger is a tool that you can run as an administrator and attach via Visual Studio to connect a running process on that machine to the source code in Visual Studio. This bridge between Visual Studio and the running process enables the developer to insert break points, pause execution of code, and analyze object values in real-time.
How Do I get Remote Debugger?
As malware has become a significant risk, be sure you only download the Remote Debugger directly from a Microsoft website. Currently, the debugger for Visual Studio 2022 is located at https://visualstudio.microsoft.com/downloads/#remote-tools-for-visual-studio-2022 (notice the microsoft.com website). It is called Remote Tools for Visual Studio 2022, and you will want to download the AMD64 version for a 64 bit Windows OS or the x86 version if running 32-bit Windows OS. Simply download it and install it on the machine where your IIS instance is hosting your Acumatica ERP instance.
Running Remote Debugger (Remote Tools for Visual Studio)
Be sure to right click the icon and select Run as Administrator, or the Remote Debugger won’t be able to attach to the system process for IIS. You should see (Administrator) in the title bar once the application is running.
Also note that it will instruct you how to connect to the remote debugger. In this case, I have run it on my local machine, and you can see that it wants me to connect to my machine named CL2278 on port 4026. When I do that successfully, it shows me the connection has been made. (We will get to that next.) Running the tool opens your computer to a security risk since anyone could connect to your running processes, so don’t run it when you don’t need it, and be sure to only run it when in a fairly secure environment.
Making the Connection from Visual Studio
To connect to the Remote Debugger from Visual Studio, go to the Debug menu and select Attach to Process…
Next, enter the server and port shown in Remote Debugger, find the IIS process (w3wp.exe), and click Attach.
At this point, Visual Studio should be attached to the process which may be on a remote server or a “remote” process running on your local machine. (This idea of running Remote Debugger locally was a game changer for my user experience for developing on my local machine.)
Now you can set breakpoints in Visual Studio and use Acumatica ERP to see execution pause at your breakpoints and inspect object values. Some particularly valuable uses for this include:
- Check to see if an event handler is being hit as expected.
- Check values in the Cache at particular points of execution.
- Step through code to see where execution goes after your breakpoint. (Note that you need to disable Just My Code in Visual Studio. Getting this to work properly is a topic for another day since you need to do more setups in Visual Studio.)
If you aren’t using Remote Debugger yet, I hope this encourages you to start. If you have been using it for remote servers but not locally, I hope you give it a try locally to see if it improves your user experience with Visual Studio as it did for me. It’s been about 3-1/2 years since Joshua Van Hoesen hooked me up with this great tool, and it’s been one of my staple tools in my toolbox ever since.