By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,977 Members | 1,369 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,977 IT Pros & Developers. It's quick & easy.

Remote Debugging - Best Practices

P: n/a
The MSDN documentation on remote debugging is a bit sparse, to say the
least, and there is almost no information available on the 'best' way to
configure this. I should note that my development system is Windows XP
Pro and the test machine is Windows 2003, both running the latest
upgrades; Visual Studio 2005 is installed on the development system and
the .Net 2.0 framework is installed on the test system. The two systems
do not have the same directory structure or physical disk layout (the
development system boots from the C drive and the test system boots from
the D drive, for example). The code being written contains some logic
that only executed properly under Windows 2003 (for example, not all WMI
information works properly from Windows XP). I log into both systems
as myself, and I always ensure that the remote debug utility is running
on the test system.

I should also note that all of the service applications I write are
coded as console applications, and if a specific command line parameter
is passed, then the code executes in console mode and not as a service.
This permits me to control the testing more effectively at certain points.

I have tried several options, some of which work and some of which do
not, and some used to work and are now failing!

1. Install Visual Studio 2005 on the test system and do development
there. Not acceptable, and not very efficient.

2. Expose the development directory as a share and set debugging to use
an external program (from the shared directory as a UNC refererence:
\\Development\ProductName\Version\Source\Services\ MyService\bin\Debug\MyService.exe),
the working directory set to the same reference, the command line set to
"-ConsoleMode", and the remote system specified. This used to work, but
now the console window pops up on the remote system and then a
SecurityException is thrown! I have verified that the zone security for
the intranet is set to full trust, which used to permit this to work,
but no more!

3. I followed the instructions on MSDN for "Remote Debugging of a
Project Built Locally", but I could not get this to work until I figured
out that the external program reference is on the remote system but the
working directory in evaluated relative to the local system! After that,
this approach worked, but it is a pain to have to copy the executable
images to the remote system every time I want to debug! I can add a
post-build command (XCOPY) to copy the files automatically, but this is
a lot of editing to modify the debug configuration each time!

4. Copy the binaries to the remote system, launch them and attach to the
running process -- this prevents me from debugging the launch process,
which is often critical, and is the reason for defining my service
applications as console applications in the first place.

Are there any better approaches? Can anyone tell me why approach #2 is
generating a SecurityException and how I might avoid this problem?

Feb 27 '06 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.