I regularly develop Visual C # applications remotely from Linux and not from MSVC for the most part, but, like you, I wanted to find a way to create and debug Windows applications and libraries on remote Windows computers, without working directly with RDP, Visual Studio etc.
It is difficult to answer this question without additional information about the development and debugging tools that you prefer to use on Linux for the types of applications you are developing. I will try to provide an overview and update the answer for more information about your workflow.
Cygwin , like MinGW MSYS , provides a Unix-like environment for Windows. Most importantly, Cygwin, unlike MinGW / MSYS, includes an implementation of the OpenSSH server, which allows us to connect to a Windows window via SSH from Linux (or any other device with an SSH client). We can install the sshd package using the Cygwin configuration utility. Once connected, Cygwin by default puts us in a Bash shell. With this feature, we can:
- Run remote commands and scripts through SSH.
- Edit files using our favorite * nix command line text editor (Vim, Emacs, etc.).
- Mount remote file systems locally using SSHFS (if Windows shares are not available).
- Redirected or tunnel ports, if necessary.
The availability of a universal shell makes almost everything possible. We can execute batch files, PowerShell scripts, and native Windows executables from the Cygwin shell in addition to Linux scripts and Cygwin programs.
For example, we could run msbuild from the command line of an SSH session to create our VC ++ application, or we could configure our local GUI editor or the IDE runs on Linux to run msbuild through SSH when we click the "build" button.
We could create a similar environment in recent versions of Windows using the Windows Subsystem for Linux ("WSL", Bash on Windows). I personally prefer Cygwin for greater portability and ease of setup. Cygwin sshd can work as a Windows service, and as an installed project Cygwin integrates very well with Windows systems (user accounts, file systems, Windows API, etc.).
Work with code
We can choose from several workflows depending on our tools and comfort level with the command line:
- Full text work; all work done through an SSH session
- Use local tools for files installed on the remote file system.
- Using local tools and file synchronization
I use the first approach. I am a big Vim user, so I connect to Windows machines via SSH to do my work on the command line using the tools and environment provided by Cygwin. The availability of tools commonly found on Linux simplifies many tasks that are difficult to complete from the default Windows console. We can write shell scripts to automate the tasks that Visual Studio could do for us. For example, I wrote a script wrapper around mstest that reads XML test results and displays them in a format that is easy to read in the terminal.
If we prefer to use a graphical editor or IDE, we can locally install the remote code so that the tools can read and write files as if they were part of the local Linux file system. We probably still need to use SSH to execute the commands needed to create the projects, but many editors allow us to configure this command as the action of the "build" project.
Sometimes the remote file system is too slow for efficient editing. In these cases, we can synchronize files between the Linux development machine and the Windows host using a tool such as rsync or the upload on save editor (for example, via SFTP), if available.
Debugging
Everything works very well until we try to find a way to debug our applications. There is currently no reasonable replacement for the Visual Studio debugger when working with Visual C ++ projects. We can debug managed C # applications running on the CLR using MDbg , but a comparable tool does not exist for C ++ programs.
We can try to use gdb (from MinGW, Cygwin, etc.) for basic low-level debugging of our own binary files, such as reading memory addresses, but the debugger does not yet support reading Microsoft debugging symbols, so the debugging experience is very limited. Microsoft started documenting the PDB format a couple of years ago, so we can see some compatibility in the future. However, it will take a long time to create a satisfactory alternative to the excellent Visual Studio debugging tools.
For debugging, RDP is currently our best option and perhaps the only mdash option. For a more natural experience, we can start Visual Studio with rdesktop (or another RDP client) and seamlessrdp to create a one-time RDP session for Visual Studio, rather than a full desktop that integrates with any window manager we use on Linux.
Sometimes we can start a full Visual Studio debugging session for simple debugging scripts by adding tracing to our application, which prints the values to the console or to a log file. In many cases, this is faster than starting the debugger.
We can also try using the Eclipse CDT debugger configured for the Visual C ++ instrumental bundle. This may allow us to perform remote debugging using an Eclipse instance on a Linux machine. I have never tried this approach, and I expect that some problems may occur when the application is linked to Microsoft libraries.