7

I have VS2013 Universal Update2 on my Win7 x64 desktop and am trying to debug a process that needs to run on the server so installed the visual studio 2013 remote debugging monitor (the x64 Update2 version) on my Windows 2008 R2 x64 server. Then modified the local VS2013 project to use remote debugging specifying the remote machine name and a C:\RemoteDebug working directory folder. It surprised me that the working directory folder was actually required on the local machine else I got a complaint it was missing, and now, I get the error

"Error while trying to run the project: Unable to start the program '<MyLocalTfsPath>\<MyProgram>.exe'. The system cannot find the file specified."

and my local executable is at the path mentioned. The remote monitor is started and tells me I connected each debug attempt so this is not a connection issue. It seems to me the local vs. remote folder locations are reversed from what I would expect with this new update (scenario 1). I know the older remote debugging (scenario 2) used "start external program" which linked to files back on the local machine, but it seems VS2013 Update 2 enhanced this and this doc

http://msdn.microsoft.com/en-us/library/8x6by8d2.aspx#BKMK_Set_up_a_Visual_C__Visual_Basic_project

implies it will publish the files on the remote machine and to do a "Start project" as you would normally do. Currently I cannot test scenario 2 since I am connecting using OpenVPN, and my server does not directly see my local desktop. So am hoping to get scenario 1 working where VS2013 does some sort of publishing. With VS2013 Update 2, what files and folders go where, and do I or VS2013 put them there? Am I understanding what VS2013 Update 2 is offering in terms of remote debugging?

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
Dave
  • 1,822
  • 2
  • 27
  • 36

1 Answers1

9

I was getting the same error but under slightly different circumstances. My development machine (lets assume this had a name of DEVMACHINE is running VS2012 and I'm trying to debug an application on a Surface Pro 2 (lets assume this had a name of REMOTEMACHINENAME. I'll give you a quick run through of the steps I followed:

  1. Install "Remote Tools for Visual Studio 2012 Update 4" on the Surface
  2. Once installed, run "Remote Debugger" from the start menu. On the first run that gave me a dialog which configures the firewall etc. See here for details
  3. Now the remote debugger should start and you should see a message in it something along the lines of "Vsvsmon started a new server named 'REMOTEMACHINENAME:4016'. Waiting for new connections."
  4. On your development machine, open VS2012. Right click on your project and select Properties
  5. In the properties window, select the Debug tab. Tick Use remote machine and enter the name of the remote machine in the field next to it (in my case REMOTEMACHINENAME)
  6. Now go to the Build tab and change Output path to be the network path to your dev machine. In my case it was something along the lines of \\DEVMACHINE\c$\projects\myapp\project\bin\x86\Debug\
  7. Save the properties
  8. Now start debugging

When I was getting the same error as you, I hadn't put in step 6 so when I was trying to debug remotely, it must have been looking for a C:\ path on the remote machine. With the network path to my dev machine in there, it worked fine.

Another quick note is that I would sometimes experience issues when trying to debug where VS2012 would throw an access denied error to the debug path for my exe. That was because the process on the remote machine had failed to stop even though I had closed the application on the remote machine and stopped debugging in VS2012. Just another thing that could bite you with this.

Barrie
  • 1,444
  • 19
  • 26
  • Basically, this is the way it always used to work. The new VS2013 doc got my hopes up that VS would publish to the debugger, so that all paths could remain local. Heck, it insisted the working directory was local... – Dave Jul 28 '14 at 13:47
  • 1
    Sorry Dave, I misunderstood what you were trying to achieve. Unfortunately I don't have VS2013 installed to have a look at how this works. From what you're saying it sounds like you are using a routed VPN. Is it possible for you to configure this as a bridged VPN so the server can see your client machine? – Barrie Jul 28 '14 at 20:45
  • I have the data center networking guy trying to setup VPN like that. Meanwhile, I'm building to a share on the server but don't want to do that all the time so it's a pita to configure back and forth. I'd rather just check the remote debug box and leave the other settings alone. At least that is what the new doc implies can be done when I compare VS2013 to the VS2010 doc at the above link. – Dave Jul 29 '14 at 13:21
  • I noticed you posted an issue with Microsoft Connect so hopefully someone there gets back to you and you can post an update here. Good luck. – Barrie Jul 29 '14 at 15:44
  • @Dave, although most likely no longer relevant - I had similar problems. If you make a new build profile in the configuration manager, you can keep your local paths. On the toolbar at the top of the IDE just change the profile from Debug to Remote Debug, or whatever you call it. [VS2015 Remote Debugging](http://gpriaulx.co/2015/12/visual-studio-2015-remote-debugging/) – Élie Dec 22 '15 at 03:57