1
votes

Everything works if I do "Attach To Process".

But I need to debug a problem during launch of an application, so I need to be able to either "Start project" or "Start external program" the remote exe.

When I do, I get "directory does not exist". (Presumably, It is either looking for this non-existent directory LOCALLY, or it lacks permissions.)

Details: * .Net Framework 3.5; C# Windows Form, with button that when clicked does

Debug.WriteLine("Hello World!");
  • Two Windows 7 Ultimate PCs, with same username and password, administrator.

Local PC:

  • Visual Studio 2010 Professional. Hello World project open and built. Tested locally: Start Debugging / hit button / see "Hello World!" in VS Output pane. Quit local version of app.

Remote PC:

  • Visual "Microsoft Visual C++ 2010 SP1 Redistributable" installed (so can run a debug version of this .Net application; before installing said "The program can't start because MSVCR100.dll is missing, when hit a breakpoint.").

  • Visual Studio Remote Debugging Monitor running.

    • says "(date/time) Msvsmon started a new server named Steve@FRESHINSTALL: Waiting for new connections".
    • When Attach to Process, says "FreshInstall\Steve connected".
  • Copy from local pc's project location (in default VS 2010 projects), \bin\debug* to C:\Code\HelloWorld*

  • Code folder is Shared with full privileges (just in case ...)

Attach to Process works fine:

  • click button => "Hello World" -- in Local PC's Output pane, just like when running locally.

Now, the problem. How LAUNCH the .exe remotely, instead of Attach to Process?

On Debug pane:

  • Tried "Start project"

  • alternatively, tried "Start external program:" C:\Code\HelloWorld\HelloWorld.exe" -- on Remote PC, this is the path to .exe

  • Working directory: "C:\Code\HelloWorld" <-- this directory ONLY exists on Remote PC (deliberately -- to make sure we aren't executing locally)

  • [checkmark] Use remote machine: FRESHINSTALL.

  • Tried with and without "Enable the Visual Studio hosting process".

When do "Start Debugging", all variations say "The working directory does not exist: "C:\Code\HelloWorld".

Well, of course not: it is on Remote PC, not locally.

Yet everywhere I look, this is what instructions say to do.

What am I supposed to do differently, or what could be wrong?


(Obviously this simple app, I could stick with Attach To Process. But I have a MUCH more complicated multiple-dll application, which is having a problem during startup. I need to breakpoint the "real" application during its start up, not after it is already running.)

(And the real situation I have to debug, is on the other side of the world, with a slow internet link. This is a local simulation of what is going wrong there. Not practical to install visual studio on the actual remote PC, to turn it into a local debugging situation. Spent a day trying to remote debug that; after I get it working on a local network, I have to duplicate the whole process with much less control over what is going on.)

1
check out my answer here stackoverflow.com/questions/11923695/… this enables you to do exactly what you want to do this assumes you can modify the code running on the remote pc - can you?wal
also if you read that link...you dont need to use remcom... assuming you make the code changes you can simply re-deploy your app and start it on the remote pc with the debug arg then it will hang until your debugger connects from your local PCwal
@wal - thanks, I will give that a try. At minimum, that will let me know if the start up is reaching the main method, or I have some more fundamental dll problem. Turning it into an "Attach to Process" approach is clever!ToolmakerSteve
have you checked the event viewer on the remote PC? may shed some light if app does not make it to mainwal
@wal Thx. Whole separate topic of configuring for more information, if that happens. On Hello World, those 5 lines of code worked perfectly: am now sitting on the Debugger.Break(); line. So, THIS step of my debugging is solved. Now I just have to take the REAL app, and get it to this point, then I am in territory I know how to handle. Thanks again.ToolmakerSteve

1 Answers

0
votes

In the interests of closing this question, to indicate that it has been addressed:

See wal's first comment on my question, and follow the link he gave, which I repeat here:

Visual Studio remote upload and debugging on other computer