There is more than one way to do this. Here is a summary of what has worked best for me.
One time SERVER MACHINE setup:
The remote debugger needs to be installed
They are constantly changing where to find it, but here is where to find it today:
One time DEVELOPER MACHINE setup
Visual Studio settings
Under tools / options then debugging / symbols:
- If the debug mode PDB files for your projects are set up to be placed to a central symbols location then make sure that location is represented in the "symbol files locations" area.
- For manageable performance: Check "Load only symbols for specified components" but do not actually specify any in the "specify include modules" window. This will only load the symbols for the components you have built and placed symbol files next to. Otherwise it can take a VERY long time to load up symbols when starting to debug.
One time EACH PROJECT settings change
- Do these changes under debug mode only.
- If a project is usually maintained by engineers who debug it on their own machines then consider not checking in these project settings changes into source control.
- If your debugging symbols PDB files get places in many different locations specific to each project, then do the steps in the previous "One time DEVELOPER MACHINE setup" section, for the project in question.
- The working directory must be set to a location that has the target components on both the local and remote machines. Research item: This might only be true for unmanaged C++.
- Within your solution, make sure the project you want to debug is set up as the "startup project", just like when debugging locally. It will give a confusing error message if you have the wrong project set for startup.
- The rest of the considerations are different for unmanaged C++ or managed C#.NET projects.
Unmanaged C++
- For debug mode unmanaged C++: Link with static libraries instead of the DLL versions. This avoids the need to install debug mode runtime libraries on the server. You may need to undefine _AFXDLL. It is unlikely your component is truly an "AFX Extension".
Under properties / configuration / debug
- Fill in the remote debugging fields to point to the server and port displayed by the remote debugger.
- I’ve had the most luck with attach set to NO, but this is because I often work on processes that run multiple instances of the same component from different processes, in which case the debugger tries to attach to ever single one of them. Unhelpful and takes a VERY long time.
- Make sure the copy of the executable you want to run is not already running on the server.
- Let the remote debugger launch your executable.
Managed C#.NET
Under properties / debug
- Check the Use Remote Machine box and fill in the machine name and port as seen in the remote debugger window on the server. E.g. servername:4024
- Set whichever command line arguments necessary.
One time GETTING READY FOR DEBUGGING steps
- Launch remote debugger
- Search "Remote Debugger" on the server.
- Make note of the machine name and port it displays.
- Set breakpoints
- Be ready to to copy components to the remote machine
- Be this post-build steps, an XCOPY script, or manually copying with file explorer. But you could be doing this over and over, so plan accordingly.
- C++
- Copy component plus the PDB file from the same build.
- C#
- Make sure all dependencies are present on the remote machine. Assemblies, config files, etc.
- Copy component. No need to copy the PDB file, it can successfully use the local one.
DEBUGGING steps
Place code to be debugged on remote machine
- Build in debug mode
- Copy components to remote machine
Start debugging
It will work like usual except:
- Choose the Remote Windows Debugger
- Some parts will take longer, especially loading symbols.
No comments:
Post a Comment