Team Remote Debugger ® 2001
Note: You may ask your question here, we will answer it at once.
1. How do I test the ASP and VB simple samples?
2. Does this debugger work on multiple projects concurrently?
3. 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?
4. 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?
5. ISAPI threads debugging: Can I monitor a specific ISAPI thread behavior? For example, if your ISAPI DLL spawns 20 threads, would it be able to tell what each thread is doing? Also, what are the things you'd need to install on the remote machine?
6. How can I debug ASP with my team?
1. How do I test the ASP and VB simple samples?
Testing ASP and VB Simple samples is very simple
:-)
>VB Sample testing:
Basically just run the Team Remote Debugger Client on your local machine.
Click "Connect" button on it to connect Team Remote Debugger Client to your local machine.
Have VB6 installed,
open Prj_VB_TRD.vbp from your installation folder
(i.e. C:\TeamRemoteDebugger_Client_Trial\Samples\Simple\VB_Simple)
Take a quick look on the lines and comments,
Run the project and click "Process Order" button,
which basically calls SplineTechDebug object and send a couple of messages and dialogs you will see on Team Remote Debugger Client windows.
After you run the project focus on Team Remote Debugger Client window.
You will see that "MySession" appeared automatically in the "3. Select Debug Session" dropdown list.
Click "Open" to open "MySession" debug session (that was created in Prj_VB_TRD).
You will see the following messages coming from Prj_VB_TRD via "MySession" debug session:
1- sys: Session Opened
1: order_id = 1001
1: ret = 1
1: Do you want to proceed with order?
1- opt: Select one option from: yes,no
Now you should select either "yes" or "no" radio buttons on the upper-right of Team Remote Debugger "\MySession - Control Mode" window. It basically waits for 10 seconds for you to select a value, you may change the timeout period by changing a parameter in the function call:
...
'7. Pass dialog with "yes" "no" buttons and wait for the answer for 10 seconds
ret = odeb.wait_for_option("yes,no", 10)
...
If you got the timeout message "1- opt: Timeout" just click the "process order" button again to restart. It is very simple.
Let's say you select "yes", you will see
1- sys: Session Opened
1: order_id = 1001
1: ret = 1
1: Do you want to proceed with order?
1- opt: Select one option from: yes,no
1- opt: Selected option: yes
1: Order Updated
1: Enter new order id
1- val: Enter a value: 1001
Now you are asked to enter whatever value you wish. That value will be passed back to your code as a return value of the function Wait_for_value and you may, for example, change a value of any variable at "debug-time" using the function Wait_for_value :-).
So just enter 10015 and click "Send Value" button
You will see:
1- sys: Session Opened
1: order_id = 1001
1: ret = 1
1: Do you want to proceed with order?
1- opt: Select one option from: yes,no
1- opt: Selected option: yes
1: Order Updated
1: Enter new order id
1- val: Enter a value: 1001
1- val: Entered value: 10015
1- sys: Session Closed
Session closed. this means the odeb is terminated and freed, which automatically close the session associated with it.
>ASP Sample testing:
To test ASP code, just put
"trd.asp"
(i.e. from C:\TeamRemoteDebugger_Client_Trial\Samples\Simple\ASP)
file in any virtual directory or web site on your intranet IIS web server, remember the IIS server name (in case it is not local) and enter the server name into "1.Enter Server Name" field of Team Remote Debugger Client, and then click "Connect".
The rest is absolutely the same as described above.
Run IE, access trd.asp - it is equal to pressing "Process Order" button in VB_Simple sample.
Open "MySession" session and watch messages and answer dialogs.
As you may have already guessed,
on the remote server you may have ASP and VB samples running at the same time, you may try and see what happens.
Also, you may have ASP and VB samples running on completely different servers (let's name them "ASPserver" and "VBServer" for the sake of simplicity) in that case you will have to connect to ASPserver, open the "ASPserver\MySession" and connect to the other one - VBServer - and open the "VBServer\MySession".
Because the server names are different you will see 2 different Team Remote Debugger Client debug session windows with
"ASPserver\MySession - Control Mode"
and
"VBServer\MySession - Control Mode"
names.
Of course you may change the "MySession" to "YourSession" :-) anytime just by changing your code from
...
'2. opening the debug session
ret = odeb.Open_Session("MySession")
...
to
...
'2. opening the debug session
ret = odeb.Open_Session("YourSession")
...
(back to top)
2. Does this debugger work on multiple projects concurrently?
Yes. You may have 10 different code units of different kind (ASP, VB, Delphi, threads, MTS, COM, COM+) on 1, 2, 3 or 10 remote servers and be able to debug all of them from the your local machine just by using the technique explained above.
And your team may do the same on the same servers. Just open different debug sessions to separate your messages from those of your
colleagues.
(back to top)
3. 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).
(back to top)
4. 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.
(back to top)
5. 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.
6. How can I debug ASP with my team?
Usually what I do is I create SplineTecDebug.C_Debug and open the session in the beginning of the ASP page and it will be closed automatically at the end of the ASP page.
So, right after @Language=... I create the C_Debug, open the debug session and wait for the connection.
In that case the session will be closed when the ASP page is finished executing.
If you want to share the same "Debug Session" between the ASP pages, you just use the same "Session Name", but create and destroy many C_Debug objects wherever you need them.
This is an absolutely normal approach.
Team Remote Debugger is designed that way to allow "connecting" many C_Debug objects to one Debug Session.
You see?
Basically, as many instances of C_Debug object can open the same "Debug Session"! And on the client you just select that Debug Session and view all messages coming from all C_Debug objects that opened the Debug Session!
If you create the C_Debug in the beginning of each of your ASP pages, you can use one Debug Session name and your colleagues can use different session names in their ASP pages they are developing!
So, you on your Team Remote Debugger Client will select your "Debug Session", and your friends theirs!
You will be debugging your code completely independently without seeing the messages of each other and noticing that other sessions are working! And even if your team consists of 10 or 50 members you all can debug independently!
The concept of debug sessions was created to allow team debugging of remote code on the shared remote server(s)!
It is also very useful, for example, when you do not have an opportunity to share the C_Debug object, but you need all messages to go through the same Debug Session and appear in the Same Debug Window. The typical example is ASP script calling MTS component. They can't share the C_Debug object, obviously, but they can share the "Debug Session", simply by naming the same "Debug Session Name".
Please feel free to ask your question here:
We will answer immediately!