This is probably a duplicate but I didn't see it... is it possible to get VC++ to launch an application for debugging on a remote machine, rather than simply attaching to an already running remote executable? Ideally I would like to build, copy the new .exe to the remote machine, and launch it through the debugger, all in some easy fashion.
Is there a nice way to do this?
For Visual Studio 2010 see the section "Launching a remote process" at http://msdn.microsoft.com/en-us/library/ff678494.aspx#scenarios (credit to https://stackoverflow.com/a/6499006/15926)
Related
I saw the documentation, but it does not show how to start the process from Visual Studio. The document says that I should manually copy the built binary to the Linux machine, run the binary on the Linux machine, and then attach VS to the process.
But this would only work if the application is in some sort of a loop, like a GUI application or web server, or in a while loop as the documentation's example below. But what if my console application is not in a loop? If I manually start it on the Linux machine, it immediately finishes its work and exits. How can I set a breakpoint at the first line in Visual Studio, and then start the process remotely from Visual Studio?
I am developing an app using Flutter, and I want to be able to test some functionality that behaves slightly different depending on the device directly on both an iPhone and an Android device.
I am using a Linux machine with Visual Studio Code as my main development machine (and do not want to change that), and on that machine Visual Studio Code is deploying to an Android emulator (or a real device).
Then I have a Mac, which has also got Visual Studio Code installed. I mounted the "lib" directory from the Linux machine via sshfs to the Mac (the rest of the Flutter project is just copied to there, since for example I do not want to share the build-folder). From there Visual Studio Code deploys the app to either the simulator or a real iPhone.
With this setup, whenever I change a file, Visual Studio Code on the Linux maching deploys directly to Android. However, since file system events do not get picked up on the Mac due to sshfs, Visual Studio Code on the Mac does not directly deploy. I only have to trigger a hot deployment though (which I mapped to F5), so even now it is only one keypress I have to do on the Mac.
My question is, can I somehow automate this last step? I was thinking about using ssh to connect from the Mac to Linux, and then pick up the filesystem events via inotify. But how could I then trigger a hot deployment on the Mac?
Is it possible to develop and build a .NET Core application locally, then push it to a remote Linux system, run it there and attach the remote debugger?
Can I execute a run script from within Visual Studio which does all the tasks via SSH? (I'm thinking of something similiar to run configuration "Shell Script" in Intellij IDE.)
I'm aware of Visual Studio Code and the remote development extension, but I'm not a fan of that IDE.
If you're thinking of something like what you could do with Java in for example Netbeans, or c++ for linux in Visual Studio, then you can't do that easily/ as conveniently with .NET core and linux unfortunately.
So, I have a project being built and test on Windows platform, since Visual Studio 2017 works and run program most comfortable for me in Windows. Now, that I have completed debug most part of the code, I'll have to change my platform built target to Linux.
I used an external project (lib) to help with the internet control, which it's built target is also Windows.
Both the project are written with under C++17 standards so cross-platform should work fine.
Following the instruction on Microsoft website, I had successfully built a test project on my remote Linux server.
However, all the tutorials seem to ask people to start up a new "Linux Project", in which I did for the test project. The question is, since I already have a project/solution created and the build target is Windows platform, is there a way to switch the build to Linux Remote Build?
I've tried opening project settings, but the "target build" option is always Windows 10 and is not changeable.
I am developing a networked Windows Store app.
Is it possible to remotely and locally debug a Windows Store app using the same instance of Visual Studio?
I have successfully set up remote debugging using a VM on my local machine.
I have a few alternatives, but I just want to know if this is currently possible. One of them is running them on multiple instances of VS. Another is installing VS on the remote machine and debug it locally as normal. (which I don't want to do as much as possible because it's really a waste of disk space)
This is how you can do this:
Build your Windows Store App in Visual Studio.
Select Local Machine on debugger toolbar. Right click on your Windows Store App Project in Solution Explorer -> Click Deploy. This will deploy latest App on Local Machine.
Select Remote Machine on debugger toolbar. Right click on your Windows Store App Project in Solution Explorer -> Click Deploy. This will deploy latest App on Remote Machine.
In Visual Studio click on Debug menu -> Debug Installed App Package. Choose Local
Machine (by default) -> find your application and click Debug.
Launch Remote Debugger on Remote Machine.
The same step as 4 above, but for Remote machine. In Visual Studio click on Debug menu -> Debug Installed App Package. Choose Remote Machine -> find your application and click Debug.
One issue you can meet:
I tried this approach with different architectures of Remote (ARM) And Local (x64) machine. My guess that each time you do Deploy - Visual Studio can rebuild your application. So in case if you will use the same architecture for Remote and Local - only for one of them you can load symbols (just try it). If you will meet this situation - you can workaround it with two ways:
Use x64 for Local Machine and x86 for remote (or vice versa). So each build / deploy will be independent.
Make a Windows Store Package for Testing. Deploy it manually on both machine and start from 4.