Team Remote Debugger ® 2001
1. What is Team Remote Debugger?
2. Do I have to attach to the process to debug with Team Remote Debugger?
4. Why do I have to add lines of code to trace my remote code?
5. I like to put a lot of debug-code in my websites, and basically leave it there. That leaves me the option to see what the website users are doing, which is a big help in handling support calls. What strategy would you recommend if I wanted to disable debugging for a website without removing all of my debug code? Right now I have "wait_for_connection=0", which seems to work ok, but I wondered if you had some input?
6. Security: Is it safe enough to leave all the debug code in my website. Could an "outside" user gain access to my debug info if he had the client installed?
1. What is Team Remote Debugger?
A: Team Remote Debugger is an unique tool that allows a developer (team of developers) to trace their remote code of any kind from their local machine(s) (more info)
2. Do I have to attach to the process to debug with Team Remote Debugger?
A: No, you do not have to attach to the process to debug remote code. In fact, team debugging is completely impossible with products that attach to the processes in order to debug it. Team Remote Debugger uses its unique internal infrastructure to pass tracing messages from servers to clients without attaching to the process.
A: Simple. In your code you create SplineTechDebug.C_Debug object (COM object), and call its methods to pass tracing messages. Check out the Programmer's Guide for more information.
4. Why do I have to add lines of code to trace my remote code?
A: In order to debug remote code, ordinary debuggers (like Visual Studio) must attach to remote process. If one debugger is attached to a remote process, no other debugger can attach to any process on that remote machine. Therefore with standard debuggers it is impossible for a team of programmers to debug code on servers from their remote machines simultaneously, not to mention that even attaching to the processes is a very hard task.
We knew all those limitations and we found the best and simplest solution for all your debugging challenges: Team Remote Debugger!
5. I like to put a lot of debug-code in my websites, and basically leave it there. That leaves me the option to see what the website users are doing, which is a big help in handling support calls. What strategy would you recommend if I wanted to _disable_ debugging for a website without removing all of my debug code? Right now I have "wait_for_connection=0", which seems to work ok, but I wondered if you had some input?
Yes, wait_for_connection = 0 will work,
also you may 'comment' the Open_Session call, in this case the C_Debug object
becomes a complete dummy that does not do anything at all. It just receives the
method calls and returns back the parameter you passed (if, of course, the
method should return something).
6. Security. Is it safe enough to leave all the debug code in my website? Could an "outside" user gain access to my debug info if he had the Client installed?
First of all, you are usually on local network
with your server and you have no firewall between you and the server, that's why
you can easily receive and send DCOM traffic back and forth between your client
and your server.
The "hacker" is outside of LAN and is separated by a firewall with
your server. Since firewalls block all DCOM traffic, (because DCOM selects
whatever ports to access remote computers), the hacker will not be able even to
connect to the server.
To fortify the security you may assign the roles with your username (or
groupname) to COM+ application / MTS package pck_splinetech with all the
components including SplineTechDeb. This will prevent anybody else to create and
use the components there. I can help you to configure that.
But basically, I do not know a single web server that accepts DCOM traffic, so I
am pretty sure you are secure there.
Besides when you comment the Open_Session call,
no message goes out of C_Debug, and nobody, including you in the intranet can't
see any message whatsoever.
That makes Team Remote Debugger fool-proof.
7. ISAPI threads
debugging:
> Can I monitor a specific ISAPI thread behavior?
Team Remote Debugger does not attach to process, therefore it allows you to debug as many threads within as many processes on as many machines as needed in parallel with other team members. But this universal behavior comes with a small price.
You should add a line of code into your source code on a remote machine that will pass messages and dialogs to your local machine. That's all.
So you write your ISAPI code, place it on a remote (local) machine, whenever your code is called (let's say from within thread #11) it will pass messages and dialogs to your local machine and you will be able to see what's going on there.
And if your team develops ISAPI extensions all of you can debug independently from each another on one (many) remote machine(s)!
That's the power of Team Remote Debugger.
You can debug your remote ISAPI threads, no matter how many of them you have and you will be pleased with the elegance the Team Remote Debugger does the job, because it allows to do the things mankind was not able to do prior to it, it allows to debug code in virtually every single tricky place in the system and in the network together with team.
> Also, what are the things you'd need to install on the remote machine?
Team Remote Debugger passes messages and dialogs from the remote (local) code to Team Remote Debugger Client.
Therefore you need to install Team Remote Debugger Server on each server and Client on your client (local) machine.
> For example, if your ISAPI DLL spawns 20 threads, would it be able to tell what each thread is doing?
To pass messages and dialogs as well as to access all the functionality of Team Remote Debugger you should create and use the COM object SplineTechDebug.C_Debug that is, obviously, in SplineTechDebug.dll that comes with Client and Server.
Because the C_Debug is a COM object you can use it from no-matter what language :VB, VC++, Delphi, C, ASP, VBScript, JavaScript etc. if, of course they support COM objects.
C_Debug has 5 methods:
First C_Debug.Open_Session("Session Name","Server Name"); In order to distinguish your debug messages from those of your colleagues you should specify "Session Name" let's say, "ISAPI_Andrew" or just "ISAPI". Leave "Server name" empty like "" to specify the current server. (read more in Programmer's Guide)
Second step is to make sure you actually opened
the "ISAPI" session on your Client:
C_Debug.Wait_For_Connection(100) // wait during 100 seconds
And then you may use C_Debug.Writeln("Hi")
C_Debug.wait_for_option("yes,no","10"); will send a dialog with "yes" "no" radio buttons. You click on one and hit "Ok"
Although the C_Debug can be on another machine in the universe :-) the execution will be blocked until the "wait_for_option" returns, effectively acting as a dialog and breakpoint, if you think about it.
It will return the "yes" string if you clicked "yes" button and "no" - if "no" etc.
And C_Debug.wait_for_value("50","10"); also sends an input dialog where you can enter whatever value and have it as a return value of this method.
That's basically it. You may check Programmer's Guide, or ask your question below, it will be answered.
A: Please feel free to ask your question here:
We will be very glad to help you!