472,126 Members | 1,523 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,126 software developers and data experts.

Remote Debugging - Best Practices

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?

-ken
Feb 27 '06 #1
0 1640

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by Development | last post: by
10 posts views Thread by Sorin Sandu | last post: by
reply views Thread by yurps | last post: by
8 posts views Thread by Nicholas Reville | last post: by
7 posts views Thread by | last post: by
1 post views Thread by CK | last post: by
3 posts views Thread by Rick | last post: by
3 posts views Thread by Yves Gagnon | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.