At my customer we are shifting left in the application delivery life cycle. A big part of this for us is equipping the developers with Dynatrace .NET agents.
After developers installed the .NET agent, breakpoints in visual studio stopped working (i.e. we received an error message saying it could not bind to the breakpoint).
I opened this matter up with support initially thinking it was unexpected behavior but realized this is expected behavior. It is expected since the agent auto-instruments the source code which will cause the source code to no longer match what the debugger thinks the source code should look like. Thus the debugger is unable to set breakpoints.
A: Turn off the agent anytime we want to debug then turn it back on afterward.
B: Use the ADK to manually instrument the code.
Workaround A is okay but I am hoping for something a little simpler to integrate into the devs' workflow.
Workaround B would technically solve the problem but this workaround would be even less appealing to the devs.
Has anyone in a similar situation to me (i.e. working with developers who use Visual Studio and trying to use .NET agents) found a better way to handle the matter of .NET agents and the VS Debugger not working in tandem?
Solved! Go to Solution.
to explain the root-cause of the behavior you see in a little more detail: the Agent transforms the IL code of specific methods (the ones that are specified by knowledge and custom sensors). this process changes the offsets so that the IL code <-> source code mappings which are provided in the .pdb files are no longer accurate. this leads to breakpoints that are set in such instrumented methods to no longer work.
so the bad news is that there's no workaround - at least none that comes to my mind - for this behavior right now.
however, the good news is, that there's a possibility in the .NET profiling API to handle such debugging/instrumentation scenarios. it's (of course) not implemented in the .NET Agent right now, but you can create an RFE (product idea) for it and we'll also keep it in the backlog for possible future enhancements.
Hi Christian, thank you for your input. While there likely is no - strictly speaking - workaround due to the fundamental difference in how these tools operate, I am hoping that there is perhaps a way to better automate the current agent-on-off workaround. By that I mean the current workflow is turning off the agent before debugging, debugging, turning on the agent, testing, repeat. Do you happen to know anything about the VS plugin? It says it has a launcher that works from VS. What I'm hoping is that this could help with the above workflow, i.e. handle the turning on and off of the agent right from VS so the devs don't have to open another tool. Thanks!
It seems like there’s a very simple solution
to the problem the developers are facing. Please make sure they configure the
.NET agent not only on the process name, but also using proper path. If they
don’t choose a path that’s used for debugging (usually
<PROJECT_DIR>\bin\debug\) than the process they use for debugging won’t
be instrumented. The path setting is available in the “Process Configuration”
section in .NET Agent configuration tool.
If the path is not configured, all processes
matching the process name will be instrumented, that also covers the process
run in the debug mode.
I have a customer experiencing some compatibility issue between MS Visual Studio and AppMon Client regarding debugger feature.
As I believe that this article may be useful for him, please would you let me know if we can move it to the Public Forums space?