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!");
Local PC:
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.
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:
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.)
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: