(Probable) Issue with remote debugging

Oct 16, 2009 at 4:07 PM
Edited Oct 19, 2009 at 6:56 AM

Hi.

First of all, let me thank you for this wonderfull plugin. Really saved me during my SharePoint solutions developments.

I'm writing because I think I could have found (and maybe fixed) a little issue related to remote debugging in the last versions of your tool (v 2 +). Please noticed: I DON'T HAVE TESTED THIS IN THE LAST 2.1.2 VERSION, only in the 2.1.1, so there is a possibility you may know this allready. But I cannot test v 2.2 now, nor I saw anything in the forums/discussion about this, so I chosed to post anyway.

 

The problem is simple: to my knowledge in some configuration the name you use to connect to the remote debugger monitor running on the server could be wrong/not sufficent. I will try to explain better my situation...
I'm working on two machine on two different domains (so I am in a cross-domain situation) - after some search on msdn configuration I have sucessfuly created the required configuration to attach to the remote debugger (aka: created two local user with the same name-password ecc ecc ecc) BUT while I could connect through the ide "Debug->Attach To Process->..." SpVisualDev still showed an error when I tried to connect.
Notice that I also use the Remote Debugger Windows Application (NOT the service!!) - perhaps this is the true cause of the problem?

I have looked at your implementation (and I must addmit that I liked how you seem to be refactoring the code while you add some new feature, many other projects just leave the initial fast&dirty code or just let the project die... Thank you again for all your effort ^_^) and to my guess the/my problem seems to reside in how you attach to the remote monitor in the class Debug Helper.

 

In the method  "debug_launch_delay_timer_Elapsed" there is a code block that looks like this:

                Debugger2 dbg2 = m_dte.Debugger as Debugger2;

                Transport trans = dbg2.Transports.Item("Default");
                Engine engine = trans.Engines.Item("Managed");

                Uri uri = new Uri(_debug_launch_target_url);
                string server = uri.Host;

                _debug_wp_process_id = _debug_launch_service_proxy.GetWebApplicationPID(_debug_launch_target_url);
                if (_debug_wp_process_id == -1)
                {
                    _debug_launch_delay_timer.Start();
                    return;
                }

                Processes processes;

                processes = dbg2.GetProcesses(trans, server);
   

The problem is that on my configuration (cannot swear that in some other situations you current implementation cannot work... I have looked at the msdn documentation for the Debugger2-Debugger3 ecc class, but to not avail - no example or description) the row "processes = dbg2.GetProcesses(trans, server)" will throw an exception. It seems that the "server name" used is not the one that the remote debugger is using.

I have noticed that if I connect using a server name identical to the one the Remote Debugger Windows Application is showing - ie somethin like "domain\username@domain" I can enumerate the process with no problems at all.

So what I have done? I simply added a new configuration setting (user, not global, so that it will be saved in the spvdinfo file and save me the "tfs hell") on the remote server page of the Artifact Configuration form called "Override Remote Debugger Server Name", so that I can pass a string to use in place of the default server name created by your original logic (that may be correct in some other situations: again, I'm not so sure of how the windows service remote debugger works, so better safe than sorry...). If the user has setted a string I use the new server name, else I just fall back to your implementation.

Now I can attach and debug my code remotly ^_^.

 

I have written this with the hope that it may be usefull to you or other people that are experiencing the same problem. If you want, just drop a word here and I will try to send you the code with my modifications.

 

PS: Thank you again for the tool. Allready said this, but belive me when I say that I really appreciate your works.

Coordinator
Oct 18, 2009 at 3:32 PM

Hi Arran,

I appriciate your comments and description of how to solve the problem with the remote debugging features. I sat up whole night a coplue of days ago trying to solve the problem so it could be available to version 2.1.2. I had come as far as how you described, I mean i found out that there should be "domain\username@domain" when GetProcesses is called. However I got logon failure messages all the time which probably only were some kind of missconfiguration on my client or remote server. It worked the few first times but then something happened so I couldn't get it to work anymore. So I decided to postpone this feature to next release where I should have more time to test it. However I put in a transport selector so you can select if you want the native transport which allow unauthenticated connection which isn't the most brilliant solution, but anyhow, it allows you to connect to your remote server without much configuration. I see this as a temporarily solution for now

Now I know that you have tested the same implementation and it seems to work so that helps me a lot!! thanks again!

Regards,

Tony

Oct 19, 2009 at 6:53 AM

My pleasure - I was trying to get that working too, so no need to thank me ^_^.

If it can help you while testing the fix (using the "domain\username@domain" server name on GetProcesses) I noticed two things - maybe that could explain why after your first attempt you started to get logon errors.

First of all - what I have done (that should help other people trying to get this work) : I have two machine, the SharePoint Server S and the client C in two different domain. I have a local account (let's call that LocalUser) on C that I copied on S (so now there are two identical local account on both machine). With that configuration I simply launch the debug monitor on the server and I'm able to connect from my client (i run VS as the local account).

That said,  while on the original testing vm I could start the debug monitor as any server user and still connect (provided that LocalUser has the debug-administrator permissions) on another identical client/server configuration I need to launch the debug monitor as the LocalUser. Could that be your case? Btw, sometimes on this second machine set I need also to increase the max idle time in the remote debugger options. That said, I was able to connect and hit a breakpoint, so the format for the server name string should be correct.

 

PS:  I would say that having a parameter for the "server name" in the artifact config. is more than enough... In my humble opinion there is no need for you to try to build that string automatically (and even if it could be done, I wonder if in some configurations the generated string couldn't be still different from the needed one - for example if you run VS and the remote debugger as different users or something similar) - after all, it could be a one-time configuration and having a specific config parameter could allow more flexibility.

 

(...And by the way, just noticed that my last post was missing the name of the method in the code snippet... i'll fix that).

Coordinator
Oct 27, 2009 at 8:36 AM

Back from SPC 2009 in Vegas so I will start digging into this remote debug problem soon. I really apriciate your input on this problem!

Regards,
Tony