I have a c# visual studio 2013 project.
I want to use remote debugging.
When setting a directory on the remote machine which is identical to the local machine (ie c:\project) it works great, but I have a special directory structure dictated by my TFS and even located on another drive which is not present on the remote machine (e:). I want to know how to define a different working directory on the remote machine from the local one.
How I got around this in Visual Studio 2015 (which is probably still relevant) is by making another build configuration for remote debugging, with the output folder set to a Windows Share on the remote machine. You can secure it with Windows Authentication, and hide the share with the 'hiddenShare$' notation.
I detail it on my blog and reference the corresponding MSDN articles here:
Remote Debugging with VS2105
I also offered a similar answer to a similar question, here:
Visual Studio 2013 remote debugging, auto deploy?
Open Configuration Manager for the solution
Add a new configuration and name it appropriately. Select the box to automatically do so for all projects.
Open the project properties of the executable project you wish to remotely debug.
Ensure that the remote debugging profile is selected.
Set the build output to the network share on the remote debugging computer.
Set the remote debugging host address and port.
Found another workaround:
Create a small virtual disk how to.
Create a batch for copying
xcopy [source] [destination] /s /e /y
Just execute batch before debugging.
It should work.
Related
I have developed a windows service on my system and have deployed the service on a target machine which does not have visual studio. Therefore, I need to debug the application from my PC. I already know how to debug a windows service on a local machine.
MY STEPS:
Copied the complete bin folder (containing .exe as well as .pdb files) to the target machine.
Installed the service on the target machine using InstallUtil.exe (i.e installUtil.exe "pathToMyServiceEXE/myService.Exe")
Started the service
Installed Visual Studio Remote Debugging application (started in "No Authentication mode" with Debugging option checked)
Attached to the service in Visual Studio (which is running on my PC)
PROBLEM: I am able to successfully attached to the windows service of the target machine. But it cannot find the symbols.
I have checked other SO questions about the same problem but could not find the correct solution so far. I have tried the following things to solve the problem:
Opened Tools->Options->Debugging->Symbols and then put the path of .pdb files on my local PC. (Didn't work)
Opened Tools->Options->Debugging->General and unchecked "Enable just my code".
In addition to above two, I have already made sure that I am running the x64 version of the Remote debugging tool, Debug/x64 version of windows service and debug/x64 on my local PC.
The best advice that I can give you - which is not the easiest now, but will pay off in the long run - is to use WinDBG debugger on the target machine. This is next to zero setup on the target machine but will require you to learn the basics of WinDBG. This is not trivial but will pay off in the long run.
Regarding why you cannot load symbols:
Maybe PDBs do not match binaries?
Maybe path is not accesible to the current logged-in user? (such as mapped drive, etc)
Maybe permission issue?
Other then that I think it should work
When I tried remote debugging with Windows Store applications (Metro applications), it was very easy. In the Start drop down I could choose one of the remote computer. Then VS built the project and automatically deployed the executable to the remote computer and ran it. It felt as if it were local debugging.
Now that I want to try remote debugging with an Windows application (simple C# Windows Forms), it was not that easy. I read the following page: http://msdn.microsoft.com/en-us/library/vstudio/8x6by8d2(v=vs.110).aspx
Does this mean I have to copy the built exe to the remote computer manually every single time when I build the project? Is there any way to make it work easily just like the Windows Store apps? Possibly a third-party extension or something?
I recently set this up for a work project, and encountered your post after experiencing similar issues. I detailed my solution on my blog.
Remote Debugging with VS2015
I changed the output folder to be a network share that my debugging account has access to, and the project build just creates output at that location, making it available to the debugger. I simply press the play (Debug) button on my toolbar with the 'Remote Debug' profile selected.
Open Configuration Manager for the solution
Add a new configuration and name it appropriately. Select the box to automatically do so for all projects.
Open the project properties of the executable project you wish to remotely debug.
Ensure that the remote debugging profile is selected.
Set the build output to the network share on the remote debugging computer.
Set the remote debugging host address and port.
Does this mean I have to copy the built exe to the remote computer
manually every single time when I build the project?
Yes.
Is there any way to make it work easily just like the Windows Store
apps?
You can create a post-build event in which you can do practically everything. In this case you can set up a xcopy/robocopy command which would copy the stuff to a network location.
Possibly a third-party extension or something?
Don't think so.
I am using these examples to build a Windows 8 app:
http://code.msdn.microsoft.com/windowsapps/Getting-started-with-C-and-41e15af5
(note: that link is stale, this is potentially the correct one: Getting started with C# and Visual Basic: Hello World samples )
When I try and run the Windows 8 device emulator, I get this error:
Error 1 Error : DEP0700 : Registration of the app failed. Rejecting a request to register from file://psf/Home/Desktop/Getting%20started%20with%20C#%20and%20Visual%20Basic%20Hello%20World%20and%20Blog%20reader%20samples%20(1)/C#/HelloWorld_Part1/bin/Debug/AppX/AppxManifest.xml because the files are on a network share. Copy the files to the local computer before registering the package. (0x80073cf9) HelloWorld_Part1
I am using Paralells on a Mac. What folder is not a network share?
I am using Parallels with a Windows 10 image and VS Community 2013.
I solved the problem with the solution proposed by #tempy above: choosing remote host in the launch configuration and writing localhost in the following screen, when it asks for the machine name.
I am able to run, debug, set breakpoints, as usual
For Visual Studio 2015:
Right-click the project
Select Properties
Select the Debug settings
Under Start options
Set Target Device to "Remote Machine"
Set Remote machine to "localhost"
I copied the files to C:\inpetpub\wwwroot and ran them from there. You cannot run the projects from pdf. VS 2012 cannot run files on a network share. I guess Paralells gets Mac files on a type of network share.
Is there a way to set up Remote Debugging (Msvscom.exe) on a machine that does not have Visual Studio installed?
I would like to attach to the service running on the VM so I can debug an issue in the code. I've done this before but both machines have had VS installed.
The Dev box is running Visual Studio 2010/Windows 7. The VM is running Windows 7 without Visual Studio.
I'm going to resurrect this because anyone who's tried to do this knows it's a complete pain in the ass every time, and that it changes slightly with every possible combination of host/remote system you can have.
Visual Studio Remote Tools Links:
Visual Studio 2010 remote debugger. (Working as of 21/Oct/2016)
Visual Studio 2013 remote tools (working as of 21/Oct/2016)
Visual Studio 2015 remote tools x86 - Direct download link
Visual Studio 2015 remote tools x64 - Direct download link
Visual Studio Tools (Thanks Robo Burned)
Visual Studio 2017 Remote Tools x64 - Direct download link (Thanks Isaac Baker)
Visual Studio 2017 Remote Tools x86 - Direct download link (Thanks Isaac Baker)
Visual Studio 2019 Remote Tools - download link
This is the setup I succeeded with today:
Host (Dev) Machine:
Windows 7 Ultimate SP1 x64. Running Visual Studio 2010, .NET Framework 4.
Remote Machine:
Industrial/Factory Floor PC running Windows Embedded Standard 32-bit. It looks/feels exactly like Windows 7. Running SP1. Visual Studio is not installed. Has the .NET framework 4.
Network:
Both machines are on the same subnet. I access the remote machine via RDP and run my application that way.
Microsoft-Proprietary Follicle-Deterioration Implementation:
Make note of your dev machine's user name and password. For some reason you have to create exactly the same user name and password on the remote machine. Because Microsoft.
How I did it:
I downloaded the Visual Studio 2010 remote debugger from the link provided by #sJhonny. I had to switch off of Visual Studio 2013 in that article and over to 2010. If you care to go over the 2010 article with a fine-tooth comb to find the download, the link is right next to the "No one ever finds this helpful" link at the top. If not, just follow my link above.
Install that on the remote machine and run the configuration wizard. I left the defaults for the wizard:
"Run the 'Visual Studio ....." was checked off
Username is LocalSystem and password is blank
Allow only computers on the local network....
Run the Remote Debugger on the remote system and you'll see
Msvsmon started a new server named 'username#machinename...'
in the interface. So far so good. Run the application on the remote machine. On the dev machine, Ctrl+Alt+P in visual studio will open "Attach to Process" (It's also under the tools menu). I got a popup about my dev machine's firewall not being configured properly and was asked if I wanted to allow the connections etc... Say yes obviously.
Enter the 'username#machinename' combination into the qualifier box... press Refresh and pray a little. Pray a little more a lot harder and you should see a list of the processes running on the remote machine. Select your process and attach to it.
But my breakpoints don't work!? Of course they don't... because using the breakpoints in the same directory as the application on the remote machine would make too much sense. If you were lucky enough, you got warned about a breakpoint cache and got shown a dialog with a path.
The dialog mentions something about it being correct relative to the remote machine. It's lying. It has nothing to do with the remote machine except that it forced you to create a brand new user over there with the same name as your current user because Microsoft. To get your breakpoints to work, follow the path on your dev machine (customizable in Tools>Options>Debugging>Symbols: Cache symbols in this directory) and copy your application's .pdb files over to that directory. You have to copy them over with every new build, unless there's an option to do it automatically; I haven't checked because I have yet to stop celebrating my remote debugging success.
Everything should work now.
certainly there is.
You can install msvsmon without installing visual studio.
I've done this myself on several machines.
the tricky part lays in authorization- the user running VS on your local machine needs special priviliges on the remote machine.
ms has some articles explaining the details- http://msdn.microsoft.com/en-us/library/bt727f1t.aspx,
Update:
Here's the links for 2017 which are not obvious to find either.
Visual Studio Remote Tools Links x64 direct link
Visual Studio Remote Tools Links x86 direct link
Taken from:
how-to-implement-remote-debugging-in-visual-studio-2005
Let's consider an example to understand this situation clearly. Molly
Clark and Adam Barr are both employees at Adventure Works. Adventure
Works has a Microsoft Windows NT domain named adventure-works.com.
Adam is having trouble with some software that Molly wrote. Molly
would like to debug this software on Adam's computer. Molly and Adam
follow these steps:
Adam doesn't have the remote debugger on his computer. To set up the remote debugger, Molly decides to share out the Program
Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger directory
on her computer. She creates a file share called Remote.
Adam runs \MollyComputerName\Remote\x86\Msvsmon.exe.
After the remote debugger starts, Adam clicks Permissions on the Tools menu to configure the remote debugger by using the Permissions
dialog box. He gives Molly permission to debug.
Note Adam could also configure the remote debugger by passing the /allow option when the remote debugger starts.
Molly starts Visual Studio 2005.
To open the Attach to Process dialog box, Molly clicks Attach to Process on the Tools menu.
Molly connects to Adam's computer by entering adventure-works.com\Adam#AdamComputerName in the Qualifier box.
Under Available Processes, Molly selects the worker process that her application is using and then clicks Attach.
Molly opens a browser and provides the URL to the remote application. The execution stops where the breakpoint is placed in
the application.
There's also another way which I prefer (if you have fast internet connection).
You don't have to download or install anything on remote desktop connection.
You can share your disk C: while connecting via Remote Desktop Connection.
On the remote desktop go to location (depending on your local location)
\\tsclient\C\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\Remote Debugger\x64
(optional) Create shortcut to folder or msvsmon.exe on desktop
Run it remotely from your local disk via shared disk. (start can take few seconds depending on your connection quality)
Option2: Copy Remote Debugger\x64 or x86 folder to the remote location and use it.
I was able to get it working with asp.net core 2.1, the only difference from the answers above was that the process you attach to is dotnet.exe.
Currently I debug my C# application locally and use watch, breakpoint and commands like step into and the debug inspector.
setup remote debugging with another machine as described here: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx
Is it possible to see the source code of remote application and go through it step-by-step as one can do locally?
Yes, you can. Just make sure that your symbol files (your .PDB files) are deployed remotely with your application.
Yes. Attaching to a remote process is just the same as attaching to a local process.