I have a beaglebone black wireless device that I am developing C# code for using Visual Studio on my windows 10 host machine. I would like to target my beaglebone board via SSH within Visual Studio so I can do a cross-platform build of my solution on my host machine (arm32), and then have that compilation run on the remote machine automatically without having to publish my solution for arm32 and transfer the binaries to the remote machine, etc. This is so I can create a Visual Studio collaboration and a colleague working remote can deploy to the remote device while in development.
I have been messing with Launch Profiles and adding my beaglebone board in the Visual Studio Cross Platform SSH connection list, as well as exploring the Attach Process area. While I can successfully connect to my beaglebone device via SSH from Visual Studio, I do not know if my real goal can be achieved. My device cannot run the Visual Studio 2022 Remote Debugger (MSVSMON) due to being a linux machine. Any assistance would be appreciated.
Related
I've written a Hello World console app in .Net Core 2.0 using VS 2017 and deployed the Debug build to a Raspberry Pi 3 running Windows 10 IoT. I can execute the app remotely via PowerShell and everything seems fine.
Having installed the Visual Studio 2017 Remote Debugging tools, I'm now trying to hook up the Remote Debugger so as I can step through my code on the Pi and I'm running into problems.
When I try to "Attach to process" from the Debug menu in Visual Studio and enter the IP and port number supplied by the IoT device portal I get the following error:
Unable to connect to the Microsoft Visual Studio Remote Debugger named '192.168.1.139:8116'. Connection request was rejected by the remote debugger. Ensure that the remote debugger is running in 'Windows Authentication' mode.
The following screenshot of the IoT Device Portal shows both the IP and Port for Remote Debug and the fact that my app (echo.exe) is running:
I've tried running the remote debugger both with and without the "Run as DefaultAccount" option checked, but this seems to make no difference.
I've also checked the firewall settings on my dev PC to ensure that it is not blocking traffic (I am connecting over the Private network)
Although the error message warns about Windows Authentication Mode, I can find no such setting for the remote debugger. Any help in getting the Remote Debugger attached and operational would be gratefully received.
You may need to select the connection type to "Remote" instead of "Default".
It works for me. You can have a try and feel free let me know if there is any problem.
One thing that I think it could help is when deploying the app to the Remote Machine and you are presented the ‘Remote Connections’ dialog you can choose there what type of authentication you want. One of the options is Windows Authentication. Try deploying and running the app like that and then the Remote Debugger should work.
In your VS Studio Project Properties -> Debug Tab -> Authentication Mode: Window Authentication
I'm trying to deploy and debug a UWP app onto a physical device. The Device is an Acer Iconia W1-810 Tab 8 running Windows 10 Home. The development environment is also Windows 10 running VS2015 Community. The Acer is set to Developer mode and the screen is unlocked.
According to my reading of this article I should be able to connect the device via USB and deploy and debug directly on the device. At first I couldn't get the PC to see the device as Windows Phone IP over USB Transport (IpOverUsbSvc) was disabled. Enabling that means I can now see the table on the network under the Phones category.
The project in VS is also set to Uninstall and then re-install my package ...
Selecting Device as the debug target in VS yields this error:
DEP6200 : Bootstrapping failed. Device cannot be found. 0x89731810:
Deployment failed because no Windows Phone was detected. Make sure a
phone is connected and powered on.
Selecting Remote Machine as the target device yeilds:
Error: Unable to connect to the Microsoft Visual Studio Remote
Debugger named '192.168.0.7'. The Visual Studio 2015 Remote Debugger
(MSVSMON.EXE) does not appear to be running on the remote computer.
This may be because a firewall is preventing communication to the
remote computer. Please see Help for assistance on configuring remote
debugging.
Which is understandable as I don't have this installed at the moment. But from my understanding the first scenario should be working and I'd rather not install a debugger on device unless absolutely required.
What do I need to configure in order to get the first debug scenario working?
It sounds like you might not have installed the visual studio remote tools on your target machine. You need to do that first before you can do any remote debugging.
Here are the instructions:
Download the Visual Studio Remote Tools from one of the links provided at https://msdn.microsoft.com/en-us/library/y7f5zaaa.aspx
Install the remote tools on the target machine
Start the remote debugger on the target machine
From visual studio click on small lack the arrow to the right of the debug button, and make sure "Remote Machine" is selected
When prompted, enter the IP of the device that you want to debug at.
(It sounds like you already know steps 4 and 5, but I included them for completeness)
I have simple one Windows Forms project with one Main form in Visual Studio 2013 Update 4, on my dev Windows 8.1 Pro PC. I also have second computer (name: REMOTEPC) with Windows 8.1 Pro and installed Visual Studio Remote Debugging Monitor 2013 Update 4. I have configured Windows Authentication and firewall settings. I have configured project properties for Debug to use remote machine to REMOTEPC:4018 and in logs I see that user REMOTEPC\username connected. I use same local and remote paths (C:\proj\bin\debug\myprogram.exe) and have manually copied all files from directory.
Now I got error:
Error while trying to run project: Unable to start program (C:\proj\bin\debug\myprogram.exe). The MSCSMON.EXE does not appear to be running on the remote computer.
As I understand it needs only one TCP 4018 port and can not find a mistake. I have read MSDN info about this, but can not figure out why its not working. Is the remote debugging for Windows Forms or WPF possible at all ?
The solution is to use to configure firewall / port forwarding if needed, for both TCP 4018 and TCP 4019. I was missing one port (4019) and now it works without a problem.
I am developing a tool to view information, Files and folders of wince device in WPF. I am able to connect, Disconnect and View Folder structure by following sample from this link.
Everything works fine on developer machine. My machine is Windows XP and I am using VS2008.But when I take WPF exe and run it on a machine where only .net framework installed I am not able to connect to device. Then I installed .net Compact Framework 3.5, and followed same steps provided in link except i don't have visual studio installed on that deployed machine.
Please provide me steps to connect to device without installing Visual Studio. And Am not sure whether it will connect to device without visual studio. So please help.
CoreCon is installed by Visual Studio, and is not available separately.
If you want to manipulate the device's file system from your PC, and the device is connected using ActiveSync/Windows Mobile Device Center, you can use the Remote API, RAPI. If you want to use C#, you can use the OpenNETCF Desktop Communication Library, which wraps up RAPI.
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.